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]

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]

I finally upgraded to 6.4 and noticed that --resume-nth only exists on klog start but not on klog switch. Was this a deliberate decision or just oversight/not deemed necessary? (I must confess that I seem to not have read the linked issue carefully enough back then^^")

I hardly ever use start and stop explicitly but often klog switch to earlier entries.

[jotaen]

No, that wasn’t deliberate, thanks for bringing that up. → #327

Although it might not make as much sense, I’d also take over the --resume flag additionally, mostly for conceptual consistency.

[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.