This will allow to bind `db/org-add-link-to-other-item` with different initial
inputs to different keys to have often used selection directly at hand.
Setting the initial input is a bit tricky, though, because
`org-refile-get-location` does not allow to set it. Instead, we have to
temporarily overwrite `completing-read` with the corresponding parameter set
directly.
This is meant to mitigate an issue with table alignment when those tables are
results of source blocks, contain links in cells and are hidden (i.e., folded):
in those circumstances, the table alignment seems to be broken, because the cell
width does not take into account that links are shorter than their textual
representation.
I am not quite sure whether this is a bug in my configuration or a bug in Org
mode itself. The function to compute cell width is `org-string-width`, but
maybe this function does not get passed the correct input when tables are folded
and need to be aligned?
This seems to be fast enough, and since I often find myself aborting a current
backlink insertion query because I missed to include all Org mode buffers,
making it the default only seems to be reasonable.
When not provided in dynamic workload reports, `start-date` and `end-date`
should be treated as unconstrainted. However, instead dates were queried
interactively in that case, because `org-read-date` is being used to normalize
date display. Fixed that.
We must widen the current restriction when searching for the template item, not
when copying the body from it. In the latter case, `org-with-point-at` will
handle the necessary widening.
When the template associated with the item at point contains sub-items itself,
those may have been assigned ID or CUSTOM_ID properties. Copying the template
would thus duplicate these properties, violating their implicit uniqueness
constraint, so we now remove those properties from the inserted checklist
template.
When a checklist template contains headings on its own, the
`CHECKLIST_INSERTED_P` property until now would be inserted at the last heading
in this template, instead of at the heading where the template is supposed to be
inserted in the first place. Fixed this.
Displaying the current filters in the mode line alone often goes unnoticed for
me, so I need a more direct display. Let's add it to the first structural
header.
Mostly moving functions around and updating page headers. Also removed some
obsolete functions, see updated command list for `db-org` use-package
declaration.
When sorting, we need the remaining efforts as numbers, so let's return those
numbers directly instead of first converting them to durations only for them to
be converted back to numbers.
This is rather experimental, but seems to work fine so far. The most
complicated part is to compute the overall clocked time of an item.
Any clocktime modifiers like “today” or “total” are currently ignored.
Not quite sure yet whether this is really it, and maybe it would be better to
create some new utility functions to ensure enough blank lines before and after
point. But let's try it out first and fix it later.
This is a convenience shortcut. Maybe the code to insert the complete checklist
also needs to go into another function, for implementatio clarity. Do this as
soon as it seems appropriate or necessary.
The current implementation of `db/org-update-headline-log-note` seems to be
fine, but if it turns out to be broken, we can try the approach of Sacha Chua.
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.
`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: 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.)
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).
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.
Experimental
Backlinks are an integral part of the checklist for the item at point, so why
not include them per default?
Copying is for now done unconditionally and without any customization. If those
will turn out necessary, then they will be added later.
This is different from the previous default start date of today, as now all past
items will also be considered. Additionally, also include the start date (or
today, if not given) to be included in the result table to show all efforts
still left for that day.
Simply replacing the first and last characters of a timestampt with `[` and `]`
is not sufficient when a time range is given with a start timestamp and an end
timestamp, because then the result would be something like `[2022-09-30 Fri
08:00>--<2022-09-30 Fri 09:00]`. So let's replace all `<` with `[` and all `>`
with `]`, just to be save.
This report will list the incremental planned workload between a given time
range using a given increment. This way, one may better at finding time to
schedule new tasks coming in.
The current implementation might be slow, because it's calling a complete
parsing process for each step in the overview report. One could instead think
about calling it only once and then disecting the individual tasks for when they
are planned specifically. But before we dive in these complications, let's
frist see whether the report is worth 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 partially reverts cff8720a44, but keeps the
doc-string.
Rationale: TOPICs may contain notes which should be reviewd regularly. Those
TOPICs should also be tagged with NOTE but could (and should) in addition
contain sub-items about concrete tasks. In this case refiling to a NOTE should
be allowed.
Maybe limiting refiling to NOTE:TOPIC combinations would be more strict here,
but I think this complexity is not (yet) worth it.
Sometimes only the backlinks to the items itself might be interesting, or
backlinks to the current item and its direct parent. To allow for easy
insertion of dynamic backlink blocks in those cases as well, include a
:parent-depth parameter. The default value of nil means no limit is imposed, as
has been the case until now.
The idea is that those entries represent project notes which should not get
tasks refiled as sub-items (sub-headings to structure these notes are fine,
though, and must be added directly). To connect tasks with project notes, use
links and backlinks instead.
This helps to prevent accidental refiling of tasks under notes and loosing them
there. A drawback is that `C-u org-refile` won't list notes as visiting targets
anymore; for this, use imenu instead.
Mostly making use of pcase-*, but I am not quite sure whether the `(,foo . ,bar)
syntax really helps …
Also adjusted some comments and some formatting.
We are interested in the backlinks so we now put them first. The backlink
targets (i.e., current item or any of its parents) are now grouped after the
priority of the item containing the backlink.
This dynamic block will list all items (including their priority) that link to
the item at point or to any of its parent items. The use case for this is to
have a series of periodic appointments where certain topics should be
discussed (“jour fixe”), and where those topics can be referenced in those
appointments via backlinks. However, simple backlinks to an item on a fixed
date is not sufficient here, as there might not be enough time on that day to
discuss all items. To avoid having to manipulate all backlinks that could not
be discussed, one could simply add a reference to the parent item of all
appointments of the jour fixe series. Using the new dynamic block introduced
here, this item will be on the list of open topics until it's closed.
