This is some relic from former configurations, and might have been wrong quite
some time now. However, in Emacs 27+, package initialization is done before
loading user-init-file, and thus we don't have to do it by hand. Before that,
package initialization was done after reading user-init-file, but before calling
after-init-hook, and since we needed to load some packages in the init file, we
had to initialize package.el ourselves.
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.
Configuring custom key bindings via use-package's :map keyword does seem to
install autoloads for the bound functions into the main helm package. I.e.,
when binding `db/play-radio-stations' to # in `helm-command-map' via :map,
use-package seems to install an autoload for `db/play-radio-stations' that
requires `helm', instead of the correct `db-music' package. Additionally,
defining key bindings somewhere in the init file is hard to manage, and they are
thus now collected with other key bindings in `db/run-init'.
`helm-mode' should actually not be activated, since we are still using ivy for
`completing-read' and friends. That being said, when we want to enable
`helm-mode' in the future, we should also not call `ivy-mode' anymore.
Autoloading helm does not work well with custom keybindings. Binding our
default "C-c h" to either `helm-command-map' or `helm-command-prefix' gives
errors, as both are not commands. In the previous configuration, the prefix
"C-c h" was initially undefined and only defined when helm was loaded. This led
to irritating behavior.
All this can be fixed by eagerly loading helm. This may slow down startup, in
particular on Windows, but it should be worth it.
It was actually only used for playing EMMS streams, but since the implementation
has been rewritten in EMMS, helm-emms does not work anymore. Replaced the radio
playing functionality by a custom function, obsoleting helm-emms.
That's not only good enough, but also much more predictable than using the
currently used shell. Customize `explicit-shell-file-name' if you don't want
bash.
Turns out the reason was another version of `python-mode' being installed in
parallel. Removing that mode fixed the issue. Standard `python-mode' together
with elpy is sufficient for now.
Then a project is set on hold, the HOLD keyword is added. When reverting the
hold state, projects go back to not having a keyword. In this case, the HOLD
tag remains, because the old trigger definition was missing a case for the empty
keyword. This is now fixed.
In our configuration, projects are headlines without TODO keywords, that are
neither periodic tasks nor dates (dates usually have todo keywords, namely GOTO
or ATTN, but sometimes dates are just for information, and then the keyword is
missing). Additionally, projects are not tagged with NOP.
This listing helps to see the current projects one is working on.
This is possible because the state triggers are working correctly now.
Note: add the WAIT keyword to all existing waiting tasks, or otherwise this
the Unsupervised view will not work correctly!
When filtering for tags instead of todo keywords, inheritance kicks in and makes
handling tasks on hold much easier: the relevant headline can be set on hold,
and all subtasks are automatically on hold as well.
The agendas for monthly reviews and notes are gone, I don't use them. My
monthly review does not look at the agenda at all, only at my backlog.
Searching notes is done using Org's search functionality, and it's working very
fine.
The „Everything“ agenda has been renamed to „Unsupervised“. The name
„Everything“ is not apt anymore, as this view clusters items that are not
displayed in the main agenda or are stuck. The name „Unsupervised“ is a little
bit better, but may also change in the future.
Add a new view for listing all items that are not periodic and not part of the
personal backlog (i.e., not tagged with SOMEWHEN). This list should help
getting an overview over the current workload of real TODO tasks. Note that
both periodic tasks (tagged with PERIODIC, i.e., series of tasks) and regular
tasks (tagged with REGULAR, i.e., repeating tasks) are excluded from this list.
Descriptions of agenda views have been extended whereever it felt necessary.
The template for simple tasks should be simple, but got more complex in the last
change. This mistake is reverted with this commit, and the usual "t" can now be
used again for simple tasks. The "T" shortcut now provides capture templates
for complex tasks, but since complex tasks are both manifold and rarer, the
capture templates are provided with two-letter shortcuts.
The `db-music' package is supposed to be an abstract interface to music
functionality, and should thus define the main hydra for this. Moreover, the
hydra should not contain „emms“ in it's name, although it's using only EMMS
functions.
It's not clear whether EMMS will every be replaced by some other backend, but
it's nicer to have a (more or less) clear separation between user frontend and
implementation backend.
The idea of having a hydra to access frequently used features is certainly nice,
but quite hard to achive when one wants to redefine the hydra every time
`db/frequently-used-features' changes. Regrettably, there are not „ephemeral
hydras“ that are created every time one would like to access it. Therefore, the
shortcuts hydra is removed for now, but may come back again when we have found a
better way to handle its dynamic nature.
Org's capture template now distinguish between simple tasks, complex
tasks (i.e., those that need a separate headline because other subtasks may
follow later) and tickets (complex tasks that have a ticket number and a
reference). Those things are necessary for work and may be helpful also
elsewhere.