Explicit overlapping entries / interruptions

[Nervengift]

Problem statement

I noticed that one thing happens pretty regularly for me:

1970-01-01 (8h!)
    9:00 - 10:25 work on #stuff 
    10:25 - 10:35 get interrupted by phone #call
    10:35 - 11:00 work on #stuff 
    11:00 - 11:30 get interrupted by #meeting
    11:30 - 12:00 work on #stuff

I feel like there should be an easier and more readable way to do handle such interruptions.

Idea 1

Since overlapping entries are usually counted twice, I'd suggest a new syntax for entries that are subtracted from the surrounding entry, but also count for themselves, e.g.

1970-01-01 (8h!)
    9:00 - 12:00 work on #stuff 
    ~ 10:25 - 10:35 get interrupted by phone #call
    ~ 11:00 - 11:30 get interrupted by #meeting

(similar to #43 this could also include parenteses around the time)

With #43 implemented, this could probably also just be syntactic sugar for

1970-01-01 (8h!)
    9:00 - 12:00 work on #stuff 
    -[10:25 - 10:35] work on #stuff
    10:25 - 10:35 get interrupted by phone #call
    -[11:00 - 11:30] work on #stuff
    11:00 - 11:30 get interrupted by #meeting

Note how we currently have to tag the negative entry with the same tags as the original entry or times for the tags are wrong

This obviously comes with a few edge cases to consider:

• entries don't actually overlap, overlap partially, or the interruption overlaps the whole original entry
• entries overlap but are in a weird order (klog seems to ignore ordering of entries currently)

It should be possible to handle all these sensibly though and maybe raise warnings.

Idea 2

Another, probably simpler but less neat imho, option might be to build something like

klog switch --previous

That still creates separate entries like in the first example but makes it less tedious to do so by setting the summary automatically

[Nervengift]

I stumbled over #42 which I had not seen initially. I guess this is basically the same thing

[jotaen]

Yeah, I think the topic of repetition is one of the shortcomings of the plain-text approach. I personally got used to that to some degree, but I think this depends a lot on the use-case, and how fine-granularly you usually create your entries.

One thing that I sometimes do is to only spell out the first entry, and then just repeat the tags for the subsequent entries. Like:

1970-01-01
    9:00 - 10:25 work on #stuff 
    10:25 - 10:35 get interrupted by phone #call
    10:35 - 11:00 #stuff 
    11:00 - 11:30 #meeting
    11:30 - 12:00 #stuff

If #work is your only “main” activity, then another option is to put the main tag into the overall record summary:

1970-01-01
A day of #work on #stuff
    9:00 - 10:25
    10:25 - 10:35 get interrupted by phone #call
    10:35 - 11:00
    11:00 - 11:30 #meeting
    11:30 - 12:00

That way, all entries inherit #work and #stuff.

This wouldn’t work if you had two main activities – e.g., say you go to the #gym later on, and there you also do a #break. In this case, one workaround is to create two records for the same date, one for #work and one for #gym (which klog allows).

I once had the thought of dividing records into multiple sections, to improve support for multiple “main” activities per record.

Both the multi sections and the time breakdown would be pretty substantial changes, however, both implementation-wise and in respect to the file format structure. I’m generally open to (re-)considering things, but I see a lot of value in the current overall simplicity of the file format, even at the expense of some convenience losses.

Regarding your second suggestion (klog switch --previous), that would be much easier to support. A similar mechanism is klog start --resume, by the way. In both cases, I could imagine for the flag to take a value, like klog start --resume 2 / klog switch --resume 2 to resume the 2nd to latest entry. The flag could default to 1, which would be the current behaviour.

[Nervengift]

Actually, since I tend to forget to switch tasks immediatly when someone calls me, I'd probably do something like this at the end of the call most of the time:

klog switch -s "random #call" -t <whenever it started>; klog switch --resume 2

But that could be a shell alias if we don't want yet another subcommand to create interruptions in the past.

[jotaen]

I just realized that it’s not possible for the --resume flag to have an optional value. It either has no value (like now), or the flag value would become mandatory. The reason is that arg parsing would become ambiguous, since the token after the flag could either be the optional flag value or a positional argument.

I’d see these following options:

• Make the value mandatory. This means, you can’t do --resume anymore, but you’d have to do --resume 1. I’m not sure this is a good idea, though, as it makes the base use-case harder.
• Introduce a new flag along the lines of --resume-nth (naming tbd). So --resume would stay as is (without value), and would effectively be equivalent to doing --resume-nth 1.

[Nervengift]

Does the argument parser allow this with the equal sign syntax like --resume without argument vs --resume=2?

But current behaviour of --resume would also not make sense for klog switch, so a new option name might be a good idea anyway.

[jotaen]

klog’s arg parser supports both formats out of the box, i.e.: --foo bar and --foo=bar, and as far as I see, the library doesn’t allow to adjust this behaviour.

I’ve tracked this idea here: #282

[Nervengift]

An issue currently is also that tags do not mix well with negative entries:

1970-01-01 
    9:00 - 17:00 #work
    -1h #break

yields

> klog tags
#break -1h
#work 8h

While I'd expect 7h of #work.

I'd have to write

1970-0101
    9:00 - 17:00 #work
    -1h #work

to get the expected result.

Is there a bug ticket/discussion for this already that I did not see?

[Nervengift]

In any case, the docs could probably use a sentence on the slightly unintuitive interactions between tags and negative time ranges. This also affects klog pause

[jotaen]

Thanks for the feedback, I’ve updated the section on tagging and tried to clarify this. If you don’t mind, feel free to take a look and let me know what you think.

[jotaen]

The issue is not really with it being plain-text but that it treats all entries as independent and does not take the order into acount, right?

Correct – klog is not opinionated about the order of entries.

[Nervengift]

Thanks for the feedback, I’ve updated the section on tagging and tried to clarify this. If you don’t mind, feel free to take a look and let me know what you think.

Thanks for the quick reaction!

I think the update makes it quite clear. Maybe you could also add a note (with a reference to the new paragraph) to the bit on klog pause. It's easy to think that it automatically removes time from your current running task (at least I did think so 😅)

[jotaen]

Ah, I see what you mean now about klog pause. I actually think this should be addressed better in klog pause itself, see this ticket.