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
templates.
As with the next action list, it's better to keep the reading list in sight so
that when I decide what to do next, it's there and showing me all the
possibilities.
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.
So far, when a link is discovered in a headline, we only keep the description of
that link. This will throw away the context of that link, which is
undesirable. So let's keep it.
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.
In that case, I sometimes want to add extra information, like scheduling a
date or adding extra references. This is not easily possible when the capture
is closed immediately.
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`.
Those will be done somewhen, if at all, and are not necessarily associated with
any action. So let's keep them off the reading list consisting of read actions.
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
list.
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.
Buffers are made globally unique, while filename usually are not, like my
various project diaries. This new setting allows to distinguish targets in
equally named org mode files directly when refiling (and thus also when
inserting links).
The `default-buffer` is apparently not optional when the current buffer is not
associated with a file. If `default-buffer` is missing and the current buffer
is not a file-buffer, e.g., a note buffer, then `org-refile-get-targets` fails.
As for eshell, path completion in shell mode erroneously adds extra spaces when
using ivy. Since the builtin completion is good enough for shell mode anyway,
let's stick to that. No bad surprises.
eshell is using pcomplete as completion meta-framework, which by default will
insert the value of `pcomplete-termination-string` to each finished completion.
However, when using newer versions of `ivy` for path completion, each completed
directory within a path is considered a finished match, and pcomplete will
insert a blank. This is annoying, and since we do not require the final blank
otherwise, we can equally just disable it.
When only signing with S/MIME, `message-encode-message-body` complained about
not being able to find \n\n. However, we only need the conversion when
encrypting with S/MIME, and apparently the LF → CRLF conversion hack is working
in that case.
However, I think there should be some way to fix this properly within Gnus,
maybe via some configuration … I think I have to write to the Gnus Usenet group
for this.
When finding the location of an Org mode item to link to,
`org-refile-get-location` may return a point even if the target buffer is not
the default buffer. Resolving point in the default buffer thus yields a false
marker and the inserted link is wrong. To remedy this, also consider the file
name returned by `org-refile-get-location` to resolve point in the file buffer
for that file.
This causes lagging while highlighting symbols, and the highlighting itself does
not add much value. Disabling it thus does not hurt and gets rid of the
lagging.
This is mostly because I haven't had time to understand what the `:custom`
keyword is actually doing. Apparently, it introduces customizations without
user interaction, which in turn makes changing default values a manual
process (by changing customizations one has never done) thus resulting in
inconsistent behavior.
As per the documentation (see "(elisp)Startup Summary"), only variable
customization that affect package initialization should go into the early init
file. Defining package archives is explicitly mentioned as something that still
may go into the main init file. So we move it there and adjust comments
accordingly.
This avoids headline-references (as opposed to referencing IDs) when implicitly
creating links in new items through `org-capture` when already in `org-capture`.
In that case, the %a template specifier will call `org-store-link`
non-interactively (as it seems) and the old setting of
`org-id-link-to-org-use-id` created links based to the headline of the target
instead of creating a new ID property.
Note that this will also always ignore CUSTOM_ID properties, but I haven't used
it anyway.
Daniel -