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.
Let's group configuration related to MIME decoding and MIME encoding, to better
understand what these variables are actually doing and to decrease maintanence
complexity.
Scoring didn't work in my IMAP mailing list folders, but not it should. In all
other folders, as long as there is no scoring file, nothing should happen.
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.
It used to be slow, but it's not the case anymore. This should help identifying
problems in my ELisp code, but might cause some trouble on Windows. Let's see …
This one works with emms 6.0 and later, even when including
`helm-source-emms-streams'. Thus, we also use the default value of
`helm-emms-default-sources' again.
This makes eshell completion use drop down menues instead of the standard
complete-until-ambiguous style I am used to. Moreover, in Org Babel shell
source blocks, ivy completion in region causes a drop down menu of possible
commands to appear after a block has been created and entered for the first
time, which not only is annoying, but also sometimes causes to cursor to
disappear (set `cursor-type' to 'bar to revert).
It's rather annoying, from my point of view. The original use case was to
complete file names in links, and this can be done by calling `company-complete'
explicitly.
The builtin default of 128 is too low, resulting in recently used commands to be
forgotten quickly, so let's use a more conservative (in the literal sense of the
word) value. Customization still takes precendence over this new default,
though.
Apparently, with the advent of Emacs 27.1, Gnus clears up everything before
startup. Sadly, this also removes any initialized registry, such that we are
left with an uninitialized registry on startup. To remedy this, let's postpone
the registry setup right after Gnus has started.
There are often small tasks that do not require the former minimum of
15 minutes, resulting in effort estimations that are too high. Conversely,
larger tasks are often hard to estimate correctly, which is why the higher
numbers are now further apart.
F9 is a comparably prominent key binding, and we now bind it to the more
important `db/org-add-link-to-other-item'. The formar binding to
`db/org-find-links-to-current-item' is bound to F11 now, since it will still be
used often, but not more often then inserting links (I think). The old binding
for F11 to `org-capture' has not been used much, and so we can dispense of it.
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.
It is not clear what function really changes the matching data, but it's called
by `org-roam--id-link-face', and this is where we save the matching data now.
TODO: check whether this has been reported or even fixed upstream.
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!