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.
To determine whether a merge is in progress, do not check in the current
directory for .git/MERGE_HEAD, but do this in the repository directory.
When computing `base-dir`, take the whole non-directory part, not just the
basename; otherwise directories like .emacs.d will get the final `.d` get
stripped off.
This allows to see of which git repository the current working directory is part
of.
This is also included in Howard Abrams configuration, but he instead determines
the name of the current git repository by looking at `remote.origin.url`.
However, my upstream branch is not always called `origin`, and sometimes there
is no upstream repository at all. Using the name of the current directory (not
the whole path, though) instead seems to be a good compromise from my point of
view.
The project is archived and no longer available from melpa, so let's keep a
local copy with us.
It might be necessary to add an extra use-package declaration with autoload
definitions, but we'll do that when it's clear it's necessary.
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.
