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.