This happens when the current buffer is already part of the Org agenda files. In this case, we do
not add the default buffer to the list of search files.
The markers involved in this check might point to the same heading, but on different positions. Try
to mitigate this by checking for equality of the ID property.
Headings with inherited tag HOLD are not shown on any agenda and thus risk being overlooked. Try to
prevent this by disallowing any heading tagged with HOLD (local or inherited) as refile target.
When a file has a bookmark, generating a link in that file (e.g. to the
line at point) results in a query from Org which link generating
function to use. This is annoying and interferes with the usual flow.
To remedy this, we simply try not to be too smart and just generate
links to bookmarks when in the bookmark menu.
This is to remove redundant references in both bookmarks and links in
Org files.
The code is based on the original implementation of `ol-bookmark.el` by
Tokuya Kameshima, as found in [org-contrib][1].
[1]: bd39cca48b/lisp/ol-bookmark.el
I tend to remove “Template” anyway when it's the only block inserted as
checklist, so let's do this automatically.
This commit also includes a minor refactoring of moving around variable
declarations to be closer to the code that actually uses them.
Previously, the last day added had been removed on the assumption that
it was the frist day after `end-date` (after which the while loop
aborts). However, when this last day is filtered because of
`:skip-matches`, this would result in accidentally removing a valid day
from the overview time period. This has been fixed by checking for this
very case, and keeping the last day added in case it is still within the
requested time period.
This is another try to reduce the number of Org items that are unfolded
when jumping to the current clock. This is particularly important with
periodic items with many subtasks, because unfolding all siblings might
be irritating (at least to me).
This reverts 05bb198.
Turns out this call is not that redundant after all. Revealing should
be done after jumping to the next checkbox of the current item.
However, revealing the item at point only then leads to funny
flickering, so let's keep the old implementation for now and reveal
stuff twice.
