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.
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.
From time to time, a new item introduces a more complex task that requires a
separate headline. The new capture template is meant for this use case: it will
ask for a ticket number (the complex tasks I currently have to deal with always
come with a ticket number), a headline description, a reference (link to
redmine ticket or something), and a first task (usually a link to the first
email from the ticket). It might be that the template is too specific, but
let's try it out first and adapt it if necessary.
Every so often, I accidentally close Emacs by confusing C-x and C-c. To prevent
this, unbind the default key binding C-x C-c for closing Emacs. Instead, we can
directly call `save-buffers-kill-emacs', what is what I am usually doing.
And, seriously, why should anyone close Emacs in the first place?
If the only item below a task is a meeting that is currently attended, and thus
marked with the ATTN keyword, then the task as stuck. Indeed, during the
meeting, new items may be added to the task at hand, so that after the meeting
is finished, the task will still be not stuck. Because of this,
`org-stuck-projects' has been updated to not classify tasks as stuck if an item
with ATTN keyword is attached to it.
I don't like to store my passwords in plain in my files. Next step should be to
cache the password, but maybe this is already achieved by using a dedicated
session?
A periodic task is a task tagged with :PERIODIC:, and whose first child is an
item called "Template". Following the template are the instances of the
periodic tasks, which constitute the actual things to do and which can be
scheduled independently of each other. Whenever such an instance is due, the
template of the periodic task is supposed to be copied to the instance as a
first step. This copying can be done manually, but of course doing it
automatically is easier. The new function added in this commit represents a
first try to add such an automatism.
Often, I want to open some file and try to first open the corresponding buffer
in the hope there's some open buffer for it already. When no such buffer
exists, I have to close the list of buffers, reopen the helm shortcut menu, and
navigate to the corresponding bookmark. This is cumbersome and somehow
duplicate work, since the bookmark and the file most often are named similarly.
With a buffer overview in the helm shortcut menu I can now search for the file
directly and if it's already open, directly select the corresponding buffer.
If it has not been opened, though, I can navigate to the corresponding bookmark
with at most one additional keystroke (C-o) and open it there. Nice!
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'.
Previously, a project was not stuck if any subtask was tagged NOP (no-project).
However, this led constellations like the following to be hidden from the stuck
project list:
* Test :NOP:
** TestTest
*** TestTestTest :NOP:
In this case, the NOP at TestTestTest would result in hiding TestTest, which,
however, does not have any more things to do and should thus be marked stuck.
The new configuration will check NOP only at the top headline, and not at any
other sub-headlines. For this, a property search TAGS={NOP} is necessary,
because otherwise tag inheritance would result in wrong false negatives.
It is no good to update `org-agenda-files' when setting those variables, only to
be overwritten by customize itself latter on. Maybe it's better to instead have
a custom setter that updates the variable, but also checks whether the file is
also contained in `org-agenda-files', warning the user if this is not the case?
Up to now, it seemed to be sufficient to set `send-mail-function' alone, but
somehow some changes have made it necessary to set `message-send-mail-function'
explicitly. If not done, it defaults to `message-send-mail-with-sendmail',
using the sendmail exectuable to send mail. At least on my machine this results
in the message being delivered to the local exim instance, which does not allow
sending remote sending of mail.
If this is necessary, clock in separately using the interruption template.
However, I have felt that this is rarely useful, to the extend that I haven't
used the note capture template just because it disturbs the clock.
Loading customizations in `db/run-init' may cause accidental overwrites of
custom settings when loading variables changes and saves values of other
customizable variables. For example, loading `custom-enabled-themes' may update
`custom-safe-themes', and if this loading happens after initialization time,
this update is directly written to custom.el via a call to
`customize-push-and-save', overwriting all remaining, i.e. not loaded, custom
settings. Loading custom settings during initialzation time prevents this
behavior.
Note that this change causes some packages to load during initialization time
that previously had been loaded only afterwards.
This allows to specify files to be loaded as the last step in `db/run-init'.
This way, custom code can be added to this Emacs configuration without
explicitly adding it to its configuration, making future merges easier.
This makes ‘db-helm’ obsolete again (already after one commit!). The function
to extract all files from ‘db/important-path’ has also been dropped in favor of
the standard ‘directory-files-recursively’. It’s not clear yet whether this
will also work on Windows, though.
This is the main entry point to play automatically generated playlists (“auto
playlists”). It is using the value of ‘db/auto-playlist-file-function’ to
generate a list of files to play. This list if currently played using EMMS, via
‘db/-emms-playlist-from-files’.
All music related functions that do not directly depend on EMMS will now go into
‘db/music’, with the intention that if we in the future replace EMMS with
something else, the API provided by ‘db/music’ will still be valid. This does
not mean, however, that functions in ‘db/music’ may not use functions from EMMS.
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).
As it seems, setting this variable to nil causes an Windows Emacs to busy wait
for input with no time delay between two cycles. This causes heavy load on the
machine and a non-reacting Emacs.
This reverts commit 529a625e67.
It’s actually not needed, and seems to have some issues with
‘org-tag-alist-for-agenda’? (But maybe these issues where present before that
change, I can’t tell anymore).