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.
This advice is experimental. It should actually not move point, but after
executing `org-agenda-redo-all`, point is at the first position of the buffer.
Further investigation necessary.
We are now not merely copying a template from another item, but more abstractly
insert a checklist consisting of backlinks and a template. Update docstring and
function name to reflect that, but keep the old name of `db/org-copy-template`
as an obsolete alias.
Nice add-on would be to automatically add a link to the new parent when
refiling, so that I can find all (former and current) sub-items by searching for
backlinks. This does not seem to be supported out of the box, is it?
This special kind of dynamic block inserts all planned tasks between two dates
and sums up it's efforts. This could help in deciding what additional tasks to
accept or what dates to promise for completion of new tasks.
This function is experimental and may need to be extended to search for IDs in a
specific password file that are is not necessarily a member of
`org-agenda-files`.
This is to mark items that are not yet actionable but are supposed to become
actionable. The intended action on those items is then to refine those (or
cancel them).
Most importantly, this allows to use globstar expansion in bash with dired.
Note that `dired` has to be invoked explicitly for this to work, as `find-file`
will not expand the globs itself.
Efforts are not necessary there anymore, so remove those to save some horizontal
space. Also add indentation to the TOPIC overview to make clear the (possibly)
hierachical structure.
Items scheduled now or in the future are now ignored by default. Rationale: if
things are scheduled now or in the future, they are displayed on the main agenda
and not overdue, so there's no need to show them in the other agendas (meant for
reviewing); if an item is scheduled in the past, it's still shown on the main
agenda, but should also be reviewd for why it's late, so we include it in the
other agendas as well.
Also ignore NOTE items that are scheduled, as the same logic applies there as
well.
Those match the current value of `org-agenda-sorting-strategy` and are thus
redundant. Removing those settings also allows to customize the order of items
in those views.
This reverts commit 690d16cdab.
Do not include complex tasks in the backlog agenda, as complex tasks are no
actionable items, but the backlog agenda should only list things that can and
should be done. Stuck complex tasks are shown in the Project agenda, and a list
of all others might only be necessary during reviews – but when complex tasks
need reviews (apart from when they are stuck), they should have a NOTE sub-item.
This list only shows complex tasks, i.e., tasks with sub-items, and is therefore
not a faithful indicator for overwork (this was the original intention to have
this list). A better indicator might be to check the Backlog Agenda, but this
list might contain items far in the future and could thus also not be a valid
indicator for overwork.
The previous version caused stack overflows in the regexp matcher, supposedly
because of matching newlines in the description. This should not happend
anymore, but description won't be matched anymore of they contain a line break.
NOP means „not a project“, so excluding them is plausible per se. NOP entries
will also be reviewed less frequently (usually once per month) so a combination
of NOTE and NOP would allow to have „abstract“ project notes whose main purpose
is to collect backlinks and thus group proper note entries (example: topics
relevant for release planning).
The idea is that items with identical priority but low effort are „more worthy“
than items with higher efforts (same gain = priority with lower effort).
Actually, the name “project” is too ambigious here, which is why I have replaced
it at some points with the more concrete word “task”. This is to mean that
tasks are items that work towards a particular, tangible goal but consist of
multiple steps to reach it. Project notes, then, capture the state of more
complex tasks with varying or multiple goals all interconnected in a specify
realm. Project notes are used for planning tasks and for capturing the current
state of affairs.
Topics, on the most abstract level, comprise areas of responsibility or activity
where not at every point in time there's something conrete to be done, but
periodic review is in order.
Related to PARA parlance (https://fortelabs.co/blog/para/), the mapping may not
be completely clear, as projects (in the sense of PARA) relate to both tasks and
project notes. Indeed, it could be the case that a project is small enough to
only have a associated task and no project notes (e.g., if everything is clear
and it's just „doing“), or a project (again in the sense of PARA) relate only to
some project notes (in my sense), e.g., when it's not yet clear or not yet
planned what needs to be done concretely or when even the goal(s) are not set
yet.
However, as far as I currently understand, the other items in the PARA
methodology map quite nicely to my terminology:
- Area of Responsibility ↔ Topics
- Resources ↔ Project Notes (or any other notes like my zettelkasten)
- Archive ↔ Archive (surprise!)
Maybe I should split my notes into two categories: project notes proper and
general notes containing information about not-necessarily-project-related
topics?
When appoints have been started but are then postponed to the future, I do not
want to see them on the WIP list. I could schedule them for the new date in
addition, but this would count the associated effort twice in the agenda view.
So let's just ignore timestamps in the future, they will show up when they are
due anyway.