This allows both a more fine-grained and more flexible control over where
templates can be located and which templates are suppoed to be used for the item
at point. This function could also be bound to a custom key binding to make it
easier to invoke.
Instead of going upward from the end, we now just start from the beginning and
skip all drawers we may encounter. This should also allow to copy subtrees in
templates, although adjustments to the headline indentations might be necessary
if the template and point are on different levels.
My checklist template are usually located in a separate file, and sometimes even
in more than one. Being able to copy those template to point is thus crucial.
Excluding NOTEs as refile targets also excludes them as jump targets for C-u C-c
C-w, which is bad. Better move all NOTEs out of the main task list into a
separate notes.org or something.
This reverts commit 90b6e91051.
NOTEs are meant to hold information for the project at hand, and not to collect
tasks, because NOTEs are meant to live longer than those tasks. Use dedicated
subprojects to group tasks. Task may (and probably should) refer to NOTEs for
keeping long lasting information, though.
This function is referenced in some doc string already, and could as well be
public, so let's make it so. This amounts to removing a dash from it's function
name.
This allows the same copy behavior as before (apart from newly introduced bugs,
that is), but in addition gives the possibility to copy bodies of arbitraty
items that can be choosen interactively. This might come in handy when copying
general checklists from anywhere in the main Org mode file to the current task.
This allows to insert links to items that were recently clocked into. The
selection to those items is done via `org-clock-select-task`, which itself will
display items from `org-clock-history`.
So far, we only considered one link in a headline and replaced it with its
description when linking to it. When there are multiple links, this will fail.
This commit changes this by iterating over all links in the headline, not only
the first one.
So far, when a link is discovered in a headline, we only keep the description of
that link. This will throw away the context of that link, which is
undesirable. So let's keep it.
When inserting links to other Org items or to the currently clocked-in item, the
complete target headline is used as a description in the newly inserted link.
When that target headline is itself a link, the newly inserted link will contain
the complete link as a description, rendering it unreadable and also
malformed (it's not allowed to have two consequtive brackets in the description
of a link). To remedy this, we now explicitly check the target headline for
being a link, and if so, only use the description of it as the description in
the newly inserted link.
When the link to another item is already present in the history of
`org-store-link`, nothing is updated. Inserting the topmost link then results
in a wrong link being inserted.
Not using `org-store-link` at all fixes this problem and also leaves the history
of `org-store-link` untouched. It also simplifies the implementation by not
relying on the complexity of `org-store-link`, but instead just only using
`org-entry-get` and `org-id-get-create`.
The `default-buffer` is apparently not optional when the current buffer is not
associated with a file. If `default-buffer` is missing and the current buffer
is not a file-buffer, e.g., a note buffer, then `org-refile-get-targets` fails.
When finding the location of an Org mode item to link to,
`org-refile-get-location` may return a point even if the target buffer is not
the default buffer. Resolving point in the default buffer thus yields a false
marker and the inserted link is wrong. To remedy this, also consider the file
name returned by `org-refile-get-location` to resolve point in the file buffer
for that file.
`org-refile-get-location` sometimes only returns a point and not a marker. In
that case, manually convert the point to a marker to ensure that calling
functions now where to go to. Additionally, ensure that
`db/org-default-org-file` is opened if not already done so, and error out if the
current buffer is not associated with a file and no default Org file exists.
We are only using the refile mechanism for convenience here, and not for actual
refiling. The refile verification function is thus not relevant here. To take
effect, we also have to ignore the cache, as it may hold precomputed targets
that have used the refile verification function in a previous run.
Sometimes an instance of a periodic tasks requires individual subtasks. In this
case, refiling there is very helpful. In other cases, the extra entries should
not be disturbing too much, I think … I hope.
Include all headlines in Org agenda files and as well as all extra text search
files in interactive selections. To make this more managable, introduce a
dedicated function to query the user for a target item.
The main entry point is now `db/org-find-links-to-current-item', which decides
how to obtain the ID and CUSTOM_ID of the item to look for. The main work is
done by `db/org-find-items-linking-to-id', which does some checks, build the
query, and then calls `org-search-view' (which, indeed, does the actual work).
Users should call `db/org-find-links-to-current-item' only.
Neither logging information not tasks should be part of that file, so keeping it
in `org-agenda-files' is not really necessary. Indeed, it has only been
included in there to allow `org-search-view' to search that file. However, with
using `org-agenda-text-search-extra-files' makes this approach obsolete.
Previously, we only copied the last element in the subtree, assuming that this
encompasses all of the content of the subtree. However, this is not true, and
thus we have to do something more elaborate. Now, starting from the end of the
subtree, we go up all elements in the subtree until we reach either the headline
or a drawer. Everything in between is copied as template to the current
location.
The shortcut in the frequently-used menu now points there, and not anymore to
the dedicated home and work files. If only a single main Org Mode file is used,
this variable should be sufficient.
If separate things should be done, generate a separate item for it, or leave
some note at the corresponding series element. Periodic tasks are quite rigid
and should not be used for collecting individual subtasks.
As described in [1], we are sometimes representing recurring tasks as lists of
single tasks plus a recurring task to create new instances once in a while. All
of this is grouped under a common headline, and those headlines should be marked
with PERIODIC to inhibit automatic clock-in.
[1]: https://karl-voit.at/2017/01/15/org-clone-subtree-with-time-shift/
RFC documents do not change over time. The custom org mode link handler
`db/org-rfc-open' now makes use of this by downloading RFC documents to
`db/rfc-cache-path' (if defined) and opening the files locally. If
`db/rfc-cache-path' is not defined, the RFC is opened in an external browser as
before.
This allows to keep a selection of used RFC documents locally on the filesystem
for future reference, without the need to retrieve them again from the IETF.
Since this is all org mode related, the handler now also resides in `db-org'
instead of `db-utils'.
The setter will now complain if the file to be added to `org-agenda-files' does
not exist and is not readable. It also now uses the proper functions from `org'
to update `org-agenda-files'.
For this a new function ‘timeline-tools-clockline-no-org-agenda-conflicts’ as
been added that reads in a clock line (start and end times), updates all org
agenda files to fix conflicting clock lines, and returns the string of the new
clock line. This works for all complete clock lines (i.e., those with end
times), but not for open clock lines (i.e., those missing an end timestamp).
Up to now, ‘org-agenda-files’ only consisted of the four variables customizable
in init.el, namly ‘db/org-default-work-file’, ‘db/org-default-home-file’,
‘db/org-default-notes-file’, and ‘db/org-default-refile-file’. However, this
meant that no *additional* agenda files were possible, like including multiple
files for notes. This should not be the case any longer.
This is achieved by moving the variable definitions to use-packages’ :init
blocks, and allowing ‘db/run-init’ to override these definitions by calling
‘load-file’ on custom.el afterwards.
Also inlined some definitions from my custom.el file back into init.el
This is a major change in the semantics of this tag: NOP now does not designated
whole projects anymore, but only headlines that should not considered by
themselves as projects. Consequently, sub-headlines of NOP-tagged headlines can
by projects on their own, and also show up as stuck projects if they are so.
The original use case, namely an underlying git-annex repository in indirect
mode, has now been changed into an (experimental) v6 git-annex repository.
Let’s see how this works out.
This function now uses the more general ‘db/org-map-clock-lines-and-entries’,
which is also going to be used by the future ‘db/org-add-clock-line-to-file’ (or
similar).
This mostly reverts 1192dc21, as it’s much clearer now what is going on, imho.
(btw: the commit message of 1192dc21 should have started with "More"
instead of "Move", duh!)
Empty strings in the variable ‘org-agenda-files’ cause exporting of the current
buffer, because "" is treated by ‘org-agenda-files’ (the function). This
results in ID properties generated in the current buffer, if this happens to be
an org-mode buffer currently selected at the time of export.
The location to which the calendar will be exported is not taken from the
customized value of ‘org-icalendar-combined-agenda-file’, which is not fixed
anymore in the configuration. If this variable is not set (i.e. nil), the no
exporting is done.
