Resume / continue activity

[nazarewk]

I propose to add klog resume command, it could be combined with klog stop for an alternative to klog pause.

It would pretty much klog start the last closed entry with an open-ended range.

1. I start with this:

   2000-01-01
       8:00-12:00 Work
       13:00-? More work
   

2. at 15:00 I'm off and run klog stop:

   2000-01-01
       8:00-12:00 Work
       13:00-15:00 More work
   

3. at 15:38 I'm back and run klog resume or klog start --resume:

   2000-01-01
       8:00-12:00 Work
       13:00-15:00 More work
       15:38-? More work
   

[jotaen]

Yeah, such a feature might come handy. A dedicated command would be a bit too much, but it could rather be a flag like klog start --resume / klog start -r, which would pick up the latest end time in the record. E.g. for:

2000-01-01
    8:00-12:00 Work
    13:00-15:00 More work

klog start --resume would yield:

2000-01-01
    8:00-12:00 Work
    13:00-15:00 More work
    15:00-?

[nazarewk]

I'm pretty sure it should add 15:00-? More work? Otherwise it is just klog start

[nazarewk]

I've added an example to better illustrate what is the goal.

Also I've implemented it myself in my klg python tool

[jotaen]

Ah I see, thanks for clarifying. Cool that you were able to work around that via your nix configs.

Regarding my comment above, I think I actually rather meant it to be klog start --continue, as in: “continue with this other activity, and make sure it strings together with my previous activity without gap”, even if you happen to invoke the command at 15:03. But I see how that is different from what you had in mind.

I think both notions of “resuming” (what you suggested) and “continuing” (what I suggested) are valid, and I’ll keep thinking about this.

[MoonCactus]

Yes, I really like the feature so much that for the last year I am using a little bash wrapper "tt" around klog and a unique log file, seemingly like @nazarewk did with Python : tt start <task>, tt stop, tt resume.

But, I went a bit further by extending the idea with tt resume <regex> : it restarts a task with the same description as the last one that matches the regex.

Because I really resume a task way more often than I create one, even if it was buried/interrupted by one or more other tasks.
Eg. to resume documentation work for a client, I would tt resume '#myclient.*documentation' (yes, I use tags for my clients). I have no need to know how far ago I worked on the tag. Also, it fails when nothing is found and ensures I have consistent descriptions and tags.

[jotaen]

Two ideas here with regards to what might be technically feasible:

• The --resume flag could take an optional parameter, along the lines of klog start --resume 2 would resume the second-to-last activity or so. (And default to 1, i.e. the last activity.)
• It might be possible to provide tab completion on the --summary flag, so that if you type klog start --summary and hit the “TAB” key, it would cycle through the existing entry summaries of the respective record

For the first iteration, I think it’s best to start with a simple version of a --resume flag as proposed, and then take it from there to see what additional improvements could be.

[MoonCactus]

Actually I used a non parametric version of resume for months and it proved pretty productive.

I would probably not use any last-N relative variant because it means I would have to read the journal and count lines in the first place, just to find the proper one. This looks like bash history !NNN (which at least relies on absolute numbering) vs !startofcommandtofind : the latter is vastly superior.

Actually before I had tt resume {keyword} what I did was this, instead : tt start (to create a blank, timed entry), then edit the journal (tt edit) and manually copy-paste the description I was looking for in the new entry !

Now, tab completion might be cool (even though it requires interactivity, with its pros and cons)

[jotaen]

klog start --resume will be included in the next release. (#259)