From time to time, a new item introduces a more complex task that requires a
separate headline. The new capture template is meant for this use case: it will
ask for a ticket number (the complex tasks I currently have to deal with always
come with a ticket number), a headline description, a reference (link to
redmine ticket or something), and a first task (usually a link to the first
email from the ticket). It might be that the template is too specific, but
let's try it out first and adapt it if necessary.
Every so often, I accidentally close Emacs by confusing C-x and C-c. To prevent
this, unbind the default key binding C-x C-c for closing Emacs. Instead, we can
directly call `save-buffers-kill-emacs', what is what I am usually doing.
And, seriously, why should anyone close Emacs in the first place?
If the only item below a task is a meeting that is currently attended, and thus
marked with the ATTN keyword, then the task as stuck. Indeed, during the
meeting, new items may be added to the task at hand, so that after the meeting
is finished, the task will still be not stuck. Because of this,
`org-stuck-projects' has been updated to not classify tasks as stuck if an item
with ATTN keyword is attached to it.
I don't like to store my passwords in plain in my files. Next step should be to
cache the password, but maybe this is already achieved by using a dedicated
session?
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/
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.