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.
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 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.
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).