Well, there wasn't any configuration for it right now, but the use-package
statement was hidden in the config section of dired's. Moved it to the
top-level right now and also bound dired-subtree-cycle.
This is for when dired+ is not available (which is current the case, because
dired+ does not seem to be available from melpa and the previously used version
was too old).
This should allow to distinguish proper tasks (“projects” in the PARA parlance)
from areas of responsibility. It currently mimics the semantics of the NOP tag,
but may be updated later on.
The present configuration is supposed to start the server if it's not already
running. Previously we checked this using `server-running-p', but this is not
really realiable. Instead, we now checking the `server-process' variable
directly.
Furthermore, if it turns out during startup that the currently configured server
file is already present, we warn the user about this and don't do anything
else. We let the user to fix it manually because it's (i) easy for the
user (easier than doing it automatically) and (ii) only done once, namly during
startup (the burden on the user is thus tenable).
The current implementation may not be accurate, though, as my understanding of
the implementation around Emacs' server functionality is only at the beginning.
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.