Whenever I try to check what I actually in the past couple of days, I
try to use a clocktable for this. However, those clocktables are
usually littered with small entries, i.e. entries where I only spent a
couple of minutes on (example: a quick chat with a colleague). Those
entries clutter the view for the relevant entries, making it hard to
make sense of past activities.
Restricting the clocktable to a certain depth somehow helps, but major
single tasks are hidden this way, and I usually want to see those.
The custom formatter added in this commit tries to alleviate this
situation by providing a mechanism to filter out those entries using a
minimum clocktime threshold. Let's see how this feature plays out.
This is especially useful when skipping weekends, but also allows for
future extensions where based on the date more complex skipping criteria
can be implemented, e.g. for holidays or vacations.
The algorithm has been simplified and has been commented where
appropriate (from my point of view). An extensive docstring has been
added to describe the intention of the approch and its recursive nature.
Those DATE entries may be relevant to the item at hand.
Caveat: the query to determine active, concurrent DATE entries is not
quite right yet, two disjoint time ranges that do not include today but
cover the past and the future would also be considered as concurrent
active date. This needs to be fixed.
The original motivation to keep this entry was to signify that backlinks
where searched for, but none where found. However, I now think that it
is enough to just rely on the code to search for relevant backlinks, and
where there are none, to just print nothing.
This function is ideal, but it's doing the job. It can be used to
format output of calls to ledger as follows:
#+begin_src emacs-lisp :results value raw table
(db/ledger-cli-to-org-table-list
(concat "ledger -f finance.ledger "
"--period monthly --depth 2 "
"--display 'd >= [2024-07-01]' "
"--empty "
"lisp ^Expense"))
#+end_src
Any item could be of interest, not only those that are valid refile
targets.
This might be slow. May we should not be using the refile mechanism to
jump to any item?
Items tagged with HOLD should be ignored in normal processes and should
thus not appear as backlinks. Items tagged WAIT are supposed to appear,
though, and are not excluded from the list of relevant backlinks.
In the previous implementation, when in some buffer which is not an Org
buffer that accidentally contains lines that partially match the regular
expression describing an Org heading, errors could occur when the Org
refile cache was empty. To address this issue, let's temporarily switch
to some Org buffer before generating the list of all Org heading
targets.
`hydra-org-clock` thus only hosts keybindings for clock-related
commands, while the new `hydra-org-jump` is for jumping to Org items in
various ways. Feels cleaner to me this way.
This is to avoid jumping back to old task that are still pointed at by
`org-clock-interrupted-task` that have long been closed. Let's see
whether this is enough to handle this case.
This will allow to bind `db/org-add-link-to-other-item` with different initial
inputs to different keys to have often used selection directly at hand.
Setting the initial input is a bit tricky, though, because
`org-refile-get-location` does not allow to set it. Instead, we have to
temporarily overwrite `completing-read` with the corresponding parameter set
directly.
This is meant to mitigate an issue with table alignment when those tables are
results of source blocks, contain links in cells and are hidden (i.e., folded):
in those circumstances, the table alignment seems to be broken, because the cell
width does not take into account that links are shorter than their textual
representation.
I am not quite sure whether this is a bug in my configuration or a bug in Org
mode itself. The function to compute cell width is `org-string-width`, but
maybe this function does not get passed the correct input when tables are folded
and need to be aligned?
This seems to be fast enough, and since I often find myself aborting a current
backlink insertion query because I missed to include all Org mode buffers,
making it the default only seems to be reasonable.
When not provided in dynamic workload reports, `start-date` and `end-date`
should be treated as unconstrainted. However, instead dates were queried
interactively in that case, because `org-read-date` is being used to normalize
date display. Fixed that.
