This is to remove redundant references in both bookmarks and links in
Org files.
The code is based on the original implementation of `ol-bookmark.el` by
Tokuya Kameshima, as found in [org-contrib][1].
[1]: bd39cca48b/lisp/ol-bookmark.el
This is akin (in purpose) to `magit-list-repositories`, but also
descends into submodules. It's not as nice as
`magit-list-repositories`, though … more of a draft version right now.
This replaces a shell script with similar purpose.
`projectile` is nice, but I rarely use a fraction of its functionality
and not having to use an external package for project management feels
more robust.
I tend to remove “Template” anyway when it's the only block inserted as
checklist, so let's do this automatically.
This commit also includes a minor refactoring of moving around variable
declarations to be closer to the code that actually uses them.
Previously, the last day added had been removed on the assumption that
it was the frist day after `end-date` (after which the while loop
aborts). However, when this last day is filtered because of
`:skip-matches`, this would result in accidentally removing a valid day
from the overview time period. This has been fixed by checking for this
very case, and keeping the last day added in case it is still within the
requested time period.
This is another try to reduce the number of Org items that are unfolded
when jumping to the current clock. This is particularly important with
periodic items with many subtasks, because unfolding all siblings might
be irritating (at least to me).
This reverts 05bb198.
Turns out this call is not that redundant after all. Revealing should
be done after jumping to the next checkbox of the current item.
However, revealing the item at point only then leads to funny
flickering, so let's keep the old implementation for now and reveal
stuff twice.
When I copy over the timeline into the actual time sheet application, I
like to focus on the first line of the remaining report, moving it to
the top of the window. Having the clocktime summary on top this hard,
because after redrawing, the summary will be on top and not the actual
timeline. Changing the positions may help here.
This change is an experimental, as quite a bit of code had to be
touched. Further testing and bug hunting will be necessary.
Workload overview reports now only allow increments of one day
(`+1d`), since the current implementation cannot accomodate for arbitray
time ranges anymore (my fault, sorry). Also, the default start time for
workload overview reports has been changed to 23:59 on the previous
day (`"-1d 23:59"`) to include the current day in the report. The
rational behind this is that since the remaining work hours of today are
now included in the computation for the report, showing the entry for
today will show an accurate estimation of the remaining work time in
contrast to a constant value.
There are now additional parameters named `:work-hours` and
`:work-items-match` that specify how much work time is available on a
day and which Org items are considered work, respectively.
`:work-hours` can also take a function to compute for a given date how
much time can be spent on work. An example could be something like
this:
```emacs-lisp
(defun db/get-worktime-for-date (date)
"Return planned working time for DATE."
;; This is a simplification, as `date' might be the start of the day or the end.
(cond
((string-match-p "Sa" date) "6:00")
((string-match-p "So\\|Sun" date) "4:00")
((string-match-p "Wed\\|Mi" date) "3:00")
(t "2:00")))
```
An example report is then the following:
```
| End Time | Planned Work | Work Hours | Utilization |
| <r> | <r> | <r> | <r> |
|------------------------+--------------+------------+-------------|
| [2024-10-06 Sun 23:59] | 1:00 | 1:00 | *100.00%* |
| [2024-10-07 Mon 23:59] | 4:15 | 3:00 | *141.67%* |
| [2024-10-08 Tue 23:59] | 7:00 | 5:00 | *140.00%* |
| [2024-10-09 Wed 23:59] | 9:15 | 8:00 | *115.62%* |
| [2024-10-10 Thu 23:59] | 12:30 | 10:00 | *125.00%* |
| [2024-10-11 Fri 23:59] | 13:15 | 12:00 | *110.42%* |
| [2024-10-12 Sat 23:59] | 19:30 | 18:00 | *108.33%* |
| [2024-10-13 Sun 23:59] | 1d 1:30 | 22:00 | *115.91%* |
| [2024-10-14 Mon 23:59] | 1d 1:45 | 1d 0:00 | *107.29%* |
| [2024-10-15 Tue 23:59] | 1d 2:30 | 1d 2:00 | *101.92%* |
|------------------------+--------------+------------+-------------|
```
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
This surpresses warnings like
> Warning (org-element): ‘org-element-at-point’ cannot be used in non-Org buffer #<buffer *Org Agenda*> (org-agenda-mode)
among others.
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 is the expected behavior, and also how `db/run-or-hide-shell` works. The
implementation is structured differently, though … because I reinvented the
implementation of `db/run-or-hide-eshell` instead of generalizing the one of
`db/run-or-hide-shell`. Ah, anyway …
Providing a non-nil universal argument to `db/load-known-ssh-keys` now readds
all known SSH keys to the current SSH agent, irregardless of whether they are
already present or not.
