Query whether there is an ongoing activity (open time range)

[lakemike]

Is there any way to get the current status? Right now I use "print" then "| tail -2 | head -1" to see what happend last.

[jotaen]

There is no such feature at the moment.

What use-case do you have in mind? Like, are you just looking for the quickest way to view the currently ongoing entry, or do you want to somehow process the ongoing entry programmatically?

[lakemike]

I call klog from iOS shortcuts ("Run script over SSH"). This is part of a simple pomodoro timer or logging of work time from either terminal, iPhone, or MacOS. Works very well. :)
So the main use case for the "status" command would be to find out what is being tracked and display it in a shortcut. I also see a small issue with the fact that start/ stop/ switch fail a bit ungracefully in case they are called in the wrong situation. Having the status would help to call either start or switch, for instance, depending on what is going on.

[jotaen]

I’ve tracked the filter idea here, I think that’s a cool enhancement: https://github.com/jotaen/klog/issues/286

Regarding the --force idea, I’d see the point, but I’m still undecided. We can continue discussing this here: #287

[lakemike]

Awesome! Thanks so much!

[ccjmne]

I used that to create a custom p10k segment and a tmux status that let me know how long I've been working on whatever it is I'm doing.
Fantastic work through and through with this tool, @jotaen!

I suppose this discussion may be marked as resolved?

[jotaen]

Thanks! For the “Feature ideas & discussions“ category, the discussion threads cannot be marked as resolved. (That’s only possible for the “Help / Question” category.)

[ccjmne]

Ah, I see, thank you, @jotaen.

[ccjmne]

After having used this solution a bit, I ran into two little related annoyances:

i. klog tags --entry-type OPEN_RANGE --today won't show me yesterday's entry that is still open (and will end up being closed after midnight—that's today).

Since we know a range can continue at most until the day immediately following that which it "belongs" to, maybe there could be a flag that lets you consider these as belonging to the queried day.

I don't presume it's an easy fix. I suppose you'd probably have it only work when:
- either --date, --today, --yesterday or --tomorrow is set (and emit a warning otherwise), AND:
- --entry-type is OPEN_RANGE,

But even then it's quite awkward, since with a single <23:00 01:00> entry on day 2, you have days 1 through 3 reporting 26 hours individually, and the period 1–2–3 also reporting 26 hours.
I can imagine this "request" would become a shift in the data modelling: don't hesitate to turn this "request" down if it's ultimately undesirable, by design.

In any case, it's trivially worked around with --since $(date -I -d'yesterday') for now, no big deal here.

---

ii. klog tags --entry-type OPEN_RANGE --with-untagged does include an (untagged) 0m entry even when there are no untagged OPEN_RANGE (nor any untagged entry for that matter).

I feel like this could conveivably be considered incorrect, but I can imagine how it came to be like that :)

Do you reckon this could be addressed?
I cannot think of an adequate work-around on my end (short of consuming klog json, but I don't want to do the arithmetic myself—even though the start_mins being allowed to go negative is a delightful touch).

[jotaen]

i. klog tags --entry-type OPEN_RANGE --today won't show me yesterday's entry that is still open (and will end up being closed after midnight—that's today).

Thanks for highlighting this. I’ve created #348 to discuss this separately, because I think it’s a bit of a broader issue.

ii. klog tags --entry-type OPEN_RANGE --with-untagged does include an (untagged) 0m entry even when there are no untagged OPEN_RANGE (nor any untagged entry for that matter).

Always including the (untagged) 0m was deliberate: my thinking was that if you explicitly want untagged entries to be counted, then the result should make a statement about that. Otherwise, it may also be confusing to say --with-untagged, and then not being able to distinguish whether there are no untagged entries, or whether the tool for whatever reason ignored the flag.

May I ask, what’s your use-case? Like, why is it a problem that klog would include that (untagged) 0m line in the output?

(For reference, the --with-untagged flag in general was discussed in #342.)

[ccjmne]

Honestly, all I want is:

1. know at any time "how long have I been working on my ongoing activity"
2. manipulate it all from the CLI most often
3. isolate my "work" context, under which everything should contribute to a daily or weekly Should-Total

Point 1. isn't all that easy, considering that I would like an Open Range to account for its immediately subsequent Negative Duration entry, if it has at least all the tags of the Open Range. This idea isn't too alien in Klog, since that's how the pause command operates.

Points 2. and 3. are only possible together if I'm using separate bookmarks.

But then, I still want my "ongoing work" indicator to work across and scan all availble bookmarks and give me legible output: (untagged) is unsatisfactory, so it means I'd have to tagged all my stuff #workin addition to have it live in its dedicated@work`-bookmark file. I propose a solution to this (though it isn't really a problem) in #349.

There was a much longer answer in there, it may be more informative but it's just too much text, it's available nonetheless in the edit history.

[ccjmne]

@jotaen, I updated my answer above, which was way too long.

[jotaen]

Citing from your edited comment:

I just realised that:

2025-01-01 (1h!)
   45m #workout

2025-01-01 (8h!)
#work
   09:00 - 18:00
   -1h

$ klog report --tag work --diff
                      Total    Should     Diff
2025 Jan    Wed  1.       8h       8h!       0m
                    ======== ========= ========
                          8h       8h!       0m

$ klog report --tag workout --diff
                      Total    Should     Diff
2025 Jan    Wed  1.      45m       1h!     -15m
                    ======== ========= ========
                         45m       1h!     -15m

What the heck?! You collect the Should-Total of the Entries that contain the selected Tag... That's pretty neat. I assumed that wouldn't be the case, my bad.

Admittedly, the interplay between should totals and tags is more of a by-effect of the inner workings of the filter mechanism, rather than a deliberate “design decision”. Right now, when applying a tag filter, the internal filter logic eliminates all entries from a record that don’t match the requested tag, and then excludes the entire record from the evaluation if no entries had been left over. That implicitly also excludes the respective should total property from the entire evaluation. I actually haven’t thought about the fact that there might be a should total on the record that may still be relevant.

Seeing this here, I actually find this behaviour a bit surprising myself, and I’m wondering whether it should be changed so should totals are always included, regardless of whether there are any matching tags.