Neither logging information not tasks should be part of that file, so keeping it
in `org-agenda-files' is not really necessary. Indeed, it has only been
included in there to allow `org-search-view' to search that file. However, with
using `org-agenda-text-search-extra-files' makes this approach obsolete.
In dired, offer all marked files, or the currently selected file if there are
none. Otherwise, just use the list of recently opened files as completing.
This is meant as a very simple replacement for dired+'s dired bookmarks.
Previously, we only copied the last element in the subtree, assuming that this
encompasses all of the content of the subtree. However, this is not true, and
thus we have to do something more elaborate. Now, starting from the end of the
subtree, we go up all elements in the subtree until we reach either the headline
or a drawer. Everything in between is copied as template to the current
location.
The shortcut in the frequently-used menu now points there, and not anymore to
the dedicated home and work files. If only a single main Org Mode file is used,
this variable should be sufficient.
Usually, only one of them is used. Maybe one day I have to replace the two
files (or, more precisely, the custom variables pointing to them) by a single
one. But then, having two files, and also two shortcuts, also remindes me of
whether I am at home or at work, and that's quite significant, isn't it?
If `db/mail-accounts' specifies accounts multiple times, or a definition for
some of these accounts is already present in `db/other-gnus-accounts', accounts
will be added multiple times with the current implementation. Apparently, Gnus
does not seem to care, but it would be better to have this fixed properly.
It's a bit clearer now what the function is doing when ARG is given, I hope. It
also turns out that switching to the current working directory does not make
much sense when we are in the shell buffer, because CWD is then just the, well,
current directory. The original logic used to CWD of the previous buffer (by
closing the shell buffer and immediately reopening it), but that's actually not
what the function is supposed to be doing, is it?
If separate things should be done, generate a separate item for it, or leave
some note at the corresponding series element. Periodic tasks are quite rigid
and should not be used for collecting individual subtasks.
The `db-music' package is supposed to be an abstract interface to music
functionality, and should thus define the main hydra for this. Moreover, the
hydra should not contain „emms“ in it's name, although it's using only EMMS
functions.
It's not clear whether EMMS will every be replaced by some other backend, but
it's nicer to have a (more or less) clear separation between user frontend and
implementation backend.
The idea of having a hydra to access frequently used features is certainly nice,
but quite hard to achive when one wants to redefine the hydra every time
`db/frequently-used-features' changes. Regrettably, there are not „ephemeral
hydras“ that are created every time one would like to access it. Therefore, the
shortcuts hydra is removed for now, but may come back again when we have found a
better way to handle its dynamic nature.
A curcial step in the conversion, namly the computation of the actual time from
the seconds since the epoch, had been conducted with too little precision. Now
the precision is fixed to a high value throughout the whole computation, and the
tests succeed again.
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.
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/
This reenables automatic gap filling in case it has been configure with
`timeline-tools-filter-functions', but somehow breaks undo of killing in the
timeline buffer. The problem seems to be that undoing a kill only restores the
killed line, but not the original line entries of the lines right before and
after the lined that had been killed. In this way, the timeline of the buffer
has overlapping entries, resulting in odd behavior.
The problem is not quite understood yet, but it seems to be that undo does not
notice the changes to the surrounding lines (maybe because they have not been
done by text editing functions).
This does not play nicely with undo, because undo won't track changes to local
variables. Thus, if we every want to have a working undo in timeline buffers,
the timeline needs to be saved as something textual. Luckily, we already store
each entry of the timeline as a text property in the timeline table, and from
now on we will extract the timeline from there whenever we need it.
Undo is still not working fully yet, there are some oddities that need to be
addressed first.
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'.
This test could not have been added before, because conversion was not
guaranteed to work for dates before the unix epoch. It now is, and we finally
can check the start of the NTP epoch! :)
The previous implementation made use of `encode-time', which is not
guaranteed to work with times before the unix epoch. Indeed, on at least one
Windows machine, the corresponding function `db/ntp-to-time' could not handle
such dates. However, Calc can handle those independently of `encode-time',
and `db/ntp-to-time' has now been reimplemented in terms of the corresponding
Calc functions.
All (both) tests still pass.
It's only necessary when editing the buffer, not when only traversing it. Moved
it to the only function where this is actually done, and added a comment to the
docstring of `timeline-tools-map-clocklines' to remind everyone that editing the
buffer through this function may yield funny surprises :)