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.
Daniel -