Feature Request : Search Logbook to find all tasks that changed state on a specific date

[xvrdm]

Thanks a lot for the great package!

I searched the doc and the issues but could not find any mention of Logbook (or drawer in general). There are mentions of clocked, deadline, scheduled...

Is it possible to find all the tasks (i.e. org headings) that were changed on a specific date?

For example, the task below would be found for search on 2021-02-17 and 2021-02-15.

* TODO Test 
  :LOGBOOK:
  - State "TODO"       from "WAIT"       [2021-02-17 Wed 10:39]
  - State "WAIT"       from "TODO"       [2021-02-15 Mon 10:30] \\
    Blabla
  :END:

[alphapapa]

Thanks for the kind words.

There isn't currently a logbook-specific predicate. You could use the ts-inactive predicate, but it wouldn't do exactly what you describe.

However, it wouldn't be too hard to define a predicate to do that. All it needs to do is make a regexp to match those lines and then search for them (probably also ensuring that any matches occur inside a logbook drawer). The existing timestamp-related predicates should be good examples to follow.

If you're interested in coding it yourself, I'll be glad to advise you, otherwise I'll put this on the list of features to add. Thanks.

[alphapapa]

Here are some early thoughts about how this feature could work. Feedback would be appreciated.

• A simple string argument, like (logbook "foo"), should match if an entry has that string in a logbook drawer.
• A sexp argument, like (logbook (ts :from "2022-01-01")), should match if an entry matches that sexp while narrowed to its logbook.
  • This might allow for optimizations such as searching for the timestamp regexp across an entire buffer and then confirming with a body predicate (which would be faster than checking every entry for a logbook).
• State changes could be handled something like (logbook :from "TODO" :to "NEXT").
  • OTOH, the :from and :to could be confused with timestamp arguments. And maybe those should be used directly, rather than using a sexp argument, e.g. (logbook :from "2022-01-01").
  • Alternative: (logbook :state ("TODO" "NEXT")) would search for changes from TODO to NEXT. It could be combined with a date, like (logbook :state ("TODO" "NEXT") :on "2022-01-01"), and to search for any state change on that date could be something like (logbook :state t :on "2022-01-01").

[alphapapa]

An early, incomplete WIP of the (logbook) predicate: https://github.com/alphapapa/org-ql/tree/wip/logbook-predicate Currently can just be used like (logbook "Called Bob") to search for entries with logbook notes mentioning that string. Later it will allow searching for notes and state changes added in specific timestamp ranges.

[hpfr]

As part of this implementation, I wonder if it might be good to modify other predicates to exclude the logbook drawer when matching. The way I see it, the logbook is for storing data that is relevant only at a certain point in time, which distinguishes it from the rest of the task body. I suppose this would be a breaking change, though.

[alphapapa]

As part of this implementation, I wonder if it might be good to modify other predicates to exclude the logbook drawer when matching. The way I see it, the logbook is for storing data that is relevant only at a certain point in time, which distinguishes it from the rest of the task body. I suppose this would be a breaking change, though.

That's an interesting idea, but probably impractical. For one, as you said, it would be a breaking change. For another, it would mean that possibly every other predicate would have to do an extra verification step after finding a potential match, which would likely be a significant performance hit. And, of course, what if the user wanted to find results that mention a string, and didn't care if it was also mentioned in a logbook?

I think that if a user needs to exclude entries that mention a certain string in a logbook, he should probably add (not (logbook "FOO")) to the query. Better to be explicit and give control to the user than to try to be "too smart" and do the wrong thing.

Having said that, it might be possible to add some kind of way to more easily prevent logbook entries from matching a query, maybe some kind of wrapper macro that would narrow each entry to exclude its logbook and then test the predicates. But that would likely mean a huge performance reduction and significant additional complexity for little benefit, so probably not a great idea.