Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and, annotations

[Daniel Mendler <mail@daniel-mendler.de>]

On 5/24/21 5:23 AM, Stefan Monnier wrote:
>>> I also don't understand why :affixation-function is given a full list of
>>> completions, when it is presumably meant to return a list of exactly the
>>> same length.
>>
>> This has the advantage in functions like read-extended-command--affixation,
>> where minibuffer-selected-window is selected only once with with-selected-window,
>> then all completions are processed in the same buffer, without the need
>> to switch buffers for every completion in a long list, as annotation-function
>> would require to do.
> 
> Why does the function use `with-selected-window`?  I can't see why it
> would need to mess with windows.  As for switching buffer, the only
> reason I can see to switch buffer is for `where-is-internal`, which
> could be fixed by pre-computing the set of keymaps (see patch below)
> which also makes sure we use the right buffer whereas
> `minibuffer-selected-window` could theoretically return another active
> minibuffer than "ours".

That is of course correct that it is better to add some internal
pre-computation. In the case of Marginalia we also have an extra caching
for the keybindings, since the `where-is-internal` function is
relatively slow. This matters when computing the keybinding annotations
on many candidates.

The context in which the `annotation/affixation-function` is computed is
not entirely clear across the set of available completion UIs, but it is
mostly the minibuffer. The solutions used in the various
annotation/affixation functions which are around are not a clean
technical solution but rather some best effort to show something useful
and hopefully correct in many scenarios. The most extensive use case are
probably our Marginalia package and the comparable ivy-rich package
(Note that ivy-rich does not make use of Ivy-specific infrastructure).

Daniel