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.
Those things are added at the end of the LOGBOOK, instead of at the beginning.
This does not help, I would rather like to have those things being added as if I
would have taken a note on the currently clocked-in task. Indeed, this is what
I have been doing instead of using those capture template, which is why this
commit removes them.
The reason to keep this off was that my solarized-theme did not have support for
this. Since I have hacked this support together on my own now, I can (and
should) also use it!
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.
Iterating over the current set of file names may not work when no files are
given (in which case all agenda files should be visisted). However, instead of
fixing the set of files, it should be more robust to find all referenced buffers
by iterating over the markers of the entries. In that case, even if a file is
visited by multiple buffers, we can be sure that the right buffers are referesh
before the timeline is redrawn.
Enabling hl-line-mode globally causes undesired and disruptive highlighting
effects in buffers such as eshell. Enabling it in prog-mode and text-mode
should be fine, though.
Additional modes may be added later.
I do not use the completion provided by company-mode, and sometimes it's even
disruptive during writing. So let's disable it for the time being.
The original reason to keep it activated has been to have completion when
inserting links to local files. This can better be achieved by providing a
universal argument to `org-insert-link`.
This will move lines more to the left when specifying arguments to constructors
or functions on multiple lines. Nested function calls can also be broken into
multiple lines to reduce their overall line width. This looks nicer from my
point of view :)
From my point of view, it does not make much sense anymore to distinguish these
two lists. Reading items should be on the main next action list as regular TODO
items. Indeed, using dedicated READ state does not make much sense either, so
let's remove that one from our capture templates, too, but keep the READ tag for
now. However, we cannot remove it from the keyword list for now as we are still
using it in some old items.
When keeping old links around, it may happen that adding another link is already
present in `org-stored-links`. In that case, only a message is displayed (“This
link already exists”), but the link itself is not pushed to the front of the
link history. A subsequent insertion of the link then requires manual selection
of the desired target, resulting in massive interruptions of the current flow.
This is the current default value from Org mode. It also makes more sense for
my workflows, as those searches usually are meant to be worked upon, and
sorting by priority helps to find the most relevant items on those lists.
Topics are reviewed regularly (e.g, every month), so having a readily available
agenda view helps here. It's also easier, I think, to keep an overview over all
active topics if they are easily accessible in a custom agenda view.
Things to refile should not be shown on the main agenda, as this view is only
meant to show open tasks. Indeed, if to-be-refiled items are already done, they
should not be here for exactly that reason; and if they are not done yet, then
they will show up in the Next Action list anyway.
Bringing items to their (supposedly) correct location is not part of doing the
item, it's part of cleaning up (e.g., while doing the weekly review).
Emptying the refile file should still be done regularly, though, i.e., every
day (via a daily review) or weekly (in the weekly review).
Those files are specific for each machine where Emacs is running and change
often, and should not be included as private configuration files. Indeed, those
files might be versioned (e.g., using git) and deploying those versioned
configuration files over multiple machines would cause a number of conflicts if
Gnus' local mail files would be included as well (as has happend to me). Since
those machine-specific files are not really relevant for other machines, keeping
them somewhere else is reasonable. The new default is $HOME/.config/gnus-news.
Note that the main gnus-newsrc file is still kept as private configuration file.
When listing files, it's not relevant whether the file is readable or whether
a symbolic link points to a non-existing file. What matters is that the file
itself exists, either as a file or as a symbolic link.
This is relevant when using `git annex find` to list files matching some search
criteria.
Those tags are meant to mark the current headline (and nothing below) as either
just a headline (via NOP, i.e., no projects) or as a topic (i.e., a general
obligation and not a concrete thing to achieve).
This tells `org-set-tags-command` to not clear the NOP tag if it's available
somewhere at a parent node – a thing `org-set-tags-command` apparently seems to
be doing in general to keep the tags hierarchy clean.
To mark whole projects as SOMEWHEN may further declutter the main project list.
To not loose sight of those SOMEWHEN projects, however, they are not explicitly
shown in the SOMEWHEN list.
The SCHEDULED entry for projects (not for their respective tasks) is now used to
move currently irrelevant projects out of sight, and schedule them for later
resubmission. Indeed, those projects will reappear on the main project list
when the SCHEDULED date is due.
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`.
plantuml-mode derives from prog-mode, which in my coniguration automatically
activates subword-mode. However, as plantuml uses barewords as strings, those
are rarely meant to be in camel-case (indeed, typos are much more common) and
subword-mode is more distracting than helpful.