When inside a file that is part of `org-agenda-file`, the default scope to
search for locations via `db/org-get-location` (used for example when
interactively inserting links) is extended to include all agenda files, and not
only the current buffer. The idea behind this is to consider all agenda files
as one large data collection, and not only individual files. This inhibits the
usual error, when trying to insert links at items located in refile.org, that
links are only displayed for items in refile.org itself – which are usually not
many – when instead links to items in the default org files where actually
requested.
This should not be an issue for performance, as searching through all agenda
files for valid locations is fast even on Windows.
The problem seems to be the dynamically scoped variable `org-time-was-given`,
which is used by `org-read-date` to decided whether an hh:mm part is present.
The variable `org-time-was-given` is set by `org-read-date-analyze`, but only
when it's (globally) bound, which it is not on startup (since it's only declared
via `defvar`). Manually setting the variable to nil binds the variable and
everything seems to work nicely.
`org-read-date` seems to have bug that it does not consider the hh:mm part of an
input string sometimes. Trying to work around this by using internal times
whenever possible, but it's not complete yet.
Found that the report will only produce reasonable output when always working on
00:00. Left a note in the docstring to warn about this, should be fixed later on.
use case: GOALs may just be tagged with :HOLD: but do not have to have the HOLD
keyword; in this case, they should also appear in this agenda view, since they
will not be shown in the stuck agenda view anymore (among others).
Use case: do not add a workload report (which usually contains links to all
current tasks) when inserting checklist backlinks; they do not carry any
information and are thus not relevant.
This is the expected behavior: when no start date is given, it should default to
today (the whole day), and not exactly now, so that day increments do not start
in the mid of the day, yielding misleading results.
When refreshing the Org agenda without completing redrawing it (i.e, by calling
`org-agenda-filter-by-tag`), effort estimates where added for every refreshing,
causing them to stack up. We now check whether a summed effort estimate is
already present and remove it before adding it again.
(Maybe one could also just skip the effort recalculation if the a summed effort
estimate is already present, but I am not sure whether this will cause display
inconsistencies when new events are added or old ones are deleted.)
Turns out `org-store-link` actually returns something and other code (e.g.,
`org-capture`) depends on this. Fix this, and on the way also recognize the
special case where `org-store-link` does not update `org-stored-links`.
This way the original function definition is left intact and can be found via
the help buffer.
The manual overwrite of `org-ql--link-regexp` has been left as it is, as it's a
`cl-defun` definition and I am not quite sure how turn this into an ELisp around
advice without breaking things.
The manual fix for `enriched-decode-display-prop` has also been left untouched,
maybe this should be an around advice as well?
From my point of view, this makes it clearer that the functions thus defined are
not meant to be used anywhere else.
Some one-time `advice-add` calls are still there, though, mostly because the
associated functions would be too long to inline them directly into their
present locations.
When adding a link to an item via `org-store-link`, and the link is not known
yet, the links is always put at the beginning of the list of currently known
links, as stored in `org-stored-links`. This allows to conveniently insert this
link via `org-insert-link` by just choosing the first element of the list, which
is selected by default.
However, when the link to the requested item is already present in
`org-stored-links`, the link is not pushed to the beginning of
`org-stored-links` by `org-store-link`, but kept where it is. When calling
`org-insert-link` to insert a link to the item, manual selection of the correct
link is required, which is annoying and unnecessarily interrupting the current
workflow. Even worse, when overlooking the notification that the link is
already stored, one will assume that the link to the requested item is at the
top of `org-stored-links` (which is isn't), subsequently inserting false links
when blindly calling `org-insert-link`. (Yes, this has happend to me …)
This patch fixes this issue by ensuring that links to items (regardless whether
they have already been known or not) are always put at the front of the
`org-stored-links`. This patch also removes the rarely used
`db/org-clear-stored-links` function, whose purpose was to provide some kind of
workaround, but turned out not to be convenient enough to actually be
used (because it also removed potentially useful links when clearing the cache).
The original version of `grep-read-files` includes file names in its default
values, giving an irritating completion candidate list when used with ivy.
Changed this to just let `completing-read` do the completion itself.
This is supposed to be the dual to DEADLINE, and shall someday release the
SCHEDULED property from its semantics to not display things before a certain
date (then the SCHEDULED property can be solely used to mean that things should
be done on a specific date).
However, the NOT_BEFORE property needs some more consistency checks, as
otherwise items that have a NOT_BEFORE property that's too far in the future may
be overlooked. Is this something for the monthly review?
Always use property matches for this, as it's more direct to me to understand
what the actual search criteria are (even if these are a bit slower). Also use
`<today>` instead of `<now>` to ignore the time part and always fall back to
00:00 time; this should avoid intra-day changes of whether an item appears on a
list or not.
These definitions are easily covered by the global setting of
`org-agenda-prefix-format` and can thus also be customized now. Note that this
yields some extra space with the default setting, as the entries of the custom
project agenda usually do not have an effort property set – but I think this is
easily bearable.
This is to signify that an Org mode item has been merged into another item,
indendent of whether the items itself has been done yet, is still in progress,
or has been cancelled.
Daniel -