plantuml-mode derives from prog-mode, which in my coniguration automatically
activates subword-mode. However, as plantuml uses barewords as strings, those
are rarely meant to be in camel-case (indeed, typos are much more common) and
subword-mode is more distracting than helpful.
So far, only a toggle for playing and pausing was available. Providing a
shortcut for `emms-stop` makes unconditionally sure the music is stoped.
Funnily(?), this also replaces an obsolete shortcut for `emms-show`.
In general, all tasks of the previous week should still be present in this week
and the week before, so there's no need to activate archive mode by default. If
it's necessary after all, it can be activated manually.
It's easier for the weekly review to see only those items that were closed, as
those may still have pending actions that need to be captured. Items not yet
closed are still available on the calendar, on the Next Action list, or
This is the same sorting as it is used in the Next Action list, and should
provide a better overview over the current items on the Waiting-For list.
Formatted the value for `org-agenda-sorting-strategy` on one line for better
readability, and also changed that for the definition of the Next Action list.
The Read capture template did not properly ask for the topic and did not have a
placement indicator for the cursor, fixed that. The Response capture template
now has a “Reply ” action word to indicate the proper action, and also has a
placement indicator in it. This way, it should be easier to use these capture
At work, I am using the category to record the cost centers of the corresponding
actions. Maybe sorting the next action list gives a better understanding of the
overall set of actions by clustering them by category?
I somehow have the feeling that my next action list is not “present” enough and
so I am afraid to miss things. As an experiments, let's try to display the next
action list in the main agenda view to always have it in sight.
So far, we only considered one link in a headline and replaced it with its
description when linking to it. When there are multiple links, this will fail.
This commit changes this by iterating over all links in the headline, not only
the first one.
When inserting links to other Org items or to the currently clocked-in item, the
complete target headline is used as a description in the newly inserted link.
When that target headline is itself a link, the newly inserted link will contain
the complete link as a description, rendering it unreadable and also
malformed (it's not allowed to have two consequtive brackets in the description
of a link). To remedy this, we now explicitly check the target headline for
being a link, and if so, only use the description of it as the description in
the newly inserted link.
Using the buffer name does not seem to play well together with org refile
keeping the last choice on top of the candidate list, because a slash is
automatically appended to this entry. This results in an invalid refile
location. Thus reverting back to only using the file name, it's fine this way.
When the link to another item is already present in the history of
`org-store-link`, nothing is updated. Inserting the topmost link then results
in a wrong link being inserted.
Not using `org-store-link` at all fixes this problem and also leaves the history
of `org-store-link` untouched. It also simplifies the implementation by not
relying on the complexity of `org-store-link`, but instead just only using
`org-entry-get` and `org-id-get-create`.
The next actions list now also contains that have a deadline, but are not being
scheduled. This is more in accordance with the GTD method, as items with a far
deadline can still be done today, and for this they have to appear in that list.
This might be used before loading pyvenv, so let's include it in the autoload
However, it seems pyvenv is loading its autoloads anyway, so this change might
be irrelevant. It's still nice to have it here for documentation.
When running this Emacs configuration on different hosts (with different
operating systems …), virtual environments for Python may be available in
different locations. So we allow the environment in which Emacs is started in
to overwrite the value of WORKON_HOME to accomodate for this.