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.
Usually, only one of them is used. Maybe one day I have to replace the two
files (or, more precisely, the custom variables pointing to them) by a single
one. But then, having two files, and also two shortcuts, also remindes me of
whether I am at home or at work, and that's quite significant, isn't it?
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.
If `db/mail-accounts' specifies accounts multiple times, or a definition for
some of these accounts is already present in `db/other-gnus-accounts', accounts
will be added multiple times with the current implementation. Apparently, Gnus
does not seem to care, but it would be better to have this fixed properly.
It's a bit clearer now what the function is doing when ARG is given, I hope. It
also turns out that switching to the current working directory does not make
much sense when we are in the shell buffer, because CWD is then just the, well,
current directory. The original logic used to CWD of the previous buffer (by
closing the shell buffer and immediately reopening it), but that's actually not
what the function is supposed to be doing, is it?
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.