As described in [1], we are sometimes representing recurring tasks as lists of
single tasks plus a recurring task to create new instances once in a while. All
of this is grouped under a common headline, and those headlines should be marked
with PERIODIC to inhibit automatic clock-in.
[1]: https://karl-voit.at/2017/01/15/org-clone-subtree-with-time-shift/
RFC documents do not change over time. The custom org mode link handler
`db/org-rfc-open' now makes use of this by downloading RFC documents to
`db/rfc-cache-path' (if defined) and opening the files locally. If
`db/rfc-cache-path' is not defined, the RFC is opened in an external browser as
before.
This allows to keep a selection of used RFC documents locally on the filesystem
for future reference, without the need to retrieve them again from the IETF.
Since this is all org mode related, the handler now also resides in `db-org'
instead of `db-utils'.
Previously, a project was not stuck if any subtask was tagged NOP (no-project).
However, this led constellations like the following to be hidden from the stuck
project list:
* Test :NOP:
** TestTest
*** TestTestTest :NOP:
In this case, the NOP at TestTestTest would result in hiding TestTest, which,
however, does not have any more things to do and should thus be marked stuck.
The new configuration will check NOP only at the top headline, and not at any
other sub-headlines. For this, a property search TAGS={NOP} is necessary,
because otherwise tag inheritance would result in wrong false negatives.
It is no good to update `org-agenda-files' when setting those variables, only to
be overwritten by customize itself latter on. Maybe it's better to instead have
a custom setter that updates the variable, but also checks whether the file is
also contained in `org-agenda-files', warning the user if this is not the case?
Up to now, it seemed to be sufficient to set `send-mail-function' alone, but
somehow some changes have made it necessary to set `message-send-mail-function'
explicitly. If not done, it defaults to `message-send-mail-with-sendmail',
using the sendmail exectuable to send mail. At least on my machine this results
in the message being delivered to the local exim instance, which does not allow
sending remote sending of mail.
If this is necessary, clock in separately using the interruption template.
However, I have felt that this is rarely useful, to the extend that I haven't
used the note capture template just because it disturbs the clock.