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.