The macro `with-current-emms-playlist' does not set the current playlist to the
current buffer, but instead switches to it. Yes, that's reasonable, but not
what I thought it does. Since I need the reverse (make the current buffer to
temporarily be the current playlist), we simply bind `emms-playlist-buffer' to
the value returned by `current-buffer'.
While we are at it, also make info loading synchronous by binding
`emms-info-asynchronously' to nil.
For this, the playlist export of EMMS is used to enable sorting by track
metadata. The current implementation is a first try and may contain some bugs
when track metadata is not readily available.
This allows easier updates of this list, without having resort to executing the
corresponding code manually. In the future, we could even update that list
automatically by attaching the new function to some of projectile's hooks or
something.
Outlook seems to expect CRLF in S/MIME signed+encrypted mails, so we add those
somewhere in the process of encoding the mail. Furthermore, Outlook is sending
MIME messages with CRLF line endings, and we have to take care of that when
looking for the end headers.
The changes proposed here are preliminary and subject to further testing.
Flycheck used to be activated unconditionally, resulting in annoying warnings
when evaluating Lisp expressions in the minibuffer with `pp-eval-expression`,
and in the scratch buffer.
This leads to errors when forgetting to fetch the complete article before
forwarding it. Moreover, redisplaying the article sometimes leads to a
completely fetched article to be displayed only partially again, resulting in
repeated fetched. Finally, the performance gain is not worth the effort in my
setup, so let's just disable it.
Sometimes an instance of a periodic tasks requires individual subtasks. In this
case, refiling there is very helpful. In other cases, the extra entries should
not be disturbing too much, I think … I hope.
Include all headlines in Org agenda files and as well as all extra text search
files in interactive selections. To make this more managable, introduce a
dedicated function to query the user for a target item.
The main entry point is now `db/org-find-links-to-current-item', which decides
how to obtain the ID and CUSTOM_ID of the item to look for. The main work is
done by `db/org-find-items-linking-to-id', which does some checks, build the
query, and then calls `org-search-view' (which, indeed, does the actual work).
Users should call `db/org-find-links-to-current-item' only.
Neither logging information not tasks should be part of that file, so keeping it
in `org-agenda-files' is not really necessary. Indeed, it has only been
included in there to allow `org-search-view' to search that file. However, with
using `org-agenda-text-search-extra-files' makes this approach obsolete.
In dired, offer all marked files, or the currently selected file if there are
none. Otherwise, just use the list of recently opened files as completing.
This is meant as a very simple replacement for dired+'s dired bookmarks.
Previously, we only copied the last element in the subtree, assuming that this
encompasses all of the content of the subtree. However, this is not true, and
thus we have to do something more elaborate. Now, starting from the end of the
subtree, we go up all elements in the subtree until we reach either the headline
or a drawer. Everything in between is copied as template to the current
location.
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?
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?
If separate things should be done, generate a separate item for it, or leave
some note at the corresponding series element. Periodic tasks are quite rigid
and should not be used for collecting individual subtasks.
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.
A curcial step in the conversion, namly the computation of the actual time from
the seconds since the epoch, had been conducted with too little precision. Now
the precision is fixed to a high value throughout the whole computation, and the
tests succeed again.
Daniel -