A periodic task is a task tagged with :PERIODIC:, and whose first child is an
item called "Template". Following the template are the instances of the
periodic tasks, which constitute the actual things to do and which can be
scheduled independently of each other. Whenever such an instance is due, the
template of the periodic task is supposed to be copied to the instance as a
first step. This copying can be done manually, but of course doing it
automatically is easier. The new function added in this commit represents a
first try to add such an automatism.
Often, I want to open some file and try to first open the corresponding buffer
in the hope there's some open buffer for it already. When no such buffer
exists, I have to close the list of buffers, reopen the helm shortcut menu, and
navigate to the corresponding bookmark. This is cumbersome and somehow
duplicate work, since the bookmark and the file most often are named similarly.
With a buffer overview in the helm shortcut menu I can now search for the file
directly and if it's already open, directly select the corresponding buffer.
If it has not been opened, though, I can navigate to the corresponding bookmark
with at most one additional keystroke (C-o) and open it there. Nice!
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.
Loading customizations in `db/run-init' may cause accidental overwrites of
custom settings when loading variables changes and saves values of other
customizable variables. For example, loading `custom-enabled-themes' may update
`custom-safe-themes', and if this loading happens after initialization time,
this update is directly written to custom.el via a call to
`customize-push-and-save', overwriting all remaining, i.e. not loaded, custom
settings. Loading custom settings during initialzation time prevents this
behavior.
Note that this change causes some packages to load during initialization time
that previously had been loaded only afterwards.
This allows to specify files to be loaded as the last step in `db/run-init'.
This way, custom code can be added to this Emacs configuration without
explicitly adding it to its configuration, making future merges easier.
This makes ‘db-helm’ obsolete again (already after one commit!). The function
to extract all files from ‘db/important-path’ has also been dropped in favor of
the standard ‘directory-files-recursively’. It’s not clear yet whether this
will also work on Windows, though.