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

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

On 5/25/21 12:46 AM, João Távora wrote:
> Daniel Mendler <mail@daniel-mendler.de> writes:
> 
>> On 5/23/21 11:54 PM, João Távora wrote:
>>> By the way, as a tangent to this, but spurred by your activity and
>>> improvements to icomplete.el, I'm also thinking of enhaving icomplete.el
>>> to allow a different type of scrolling in icomplete-vertical-mode where
>>> the active completion isn't necessarily shown in the screen line of the
>>> minibuffer.  So that it acts more like a classic dropdown.  Kind of
>>> company-mode but in the minibuffer.
>>
>> You may want to take a look at my Vertico package which is on GNU ELPA.
>> It is basically a reimplementation of Icomplete with a classic dropdown.
>> The inner workings are similar to Icomplete. The main technical
>> difference is that Icomplete rotates the candidates, while Vertico keeps
>> an index.
> 
> I think rotation makes sense in vanilla icomplete, but not in
> icomplete-vertical-mode.  So for the latter, I think I will just take
> the cue from Vertico and use an index (or equivalent).  Since it's in
> GNU ELPA, maybe even borrow some code :-)

Oh, I disagree here. I think Icomplete should continue to use rotations,
since this is what Icomplete is. Why bake in two very different modi
inside Icomplete, given that Vertico exists? Honestly, I think it would
be better than just import Vertico into Emacs then. Of course it also
lives happily on ELPA.

Baking two such different modi in Icomplete only complicates things and
I don't consider Icomplete a clean implementation actually, since it
bakes both `completion-in-region` and `completing-read` into one package
(see my criticism on the README of Vertico and Corfu). Vertico and Corfu
are deliberately separate to have the ability to optimize the
`completion-in-region` and `completing-read` UI separately.

Instead of using an index you could still use the rotations and only
reorganize the display such that the current candidate is not visualized
on the top. I think using rotations is even necessary if you want to
continue to use the default completion functions which take the first
candidate of the list into account. Of course you can change these inner
workings too (I am talking about completion-all-sorted-completions).

But I am really not sure what the point is of this in Icomplete. Maybe
it makes sense to decouple/deconstruct the minibuffer.el implementation
more such that the completion backend functionality is more separate
from the display functionality.

>>> Another idea is to make icomplete work for
>>> `completion-in-region-function`.
>>
>> Icomplete already should somehow work as a
>> `completion-in-region-function`, but I think it is a bit brittle.
> 
> I have a vague recollection that Someone Somewhere (tm) in one of my
> extensions over at GitHub tried it out and found it could mostly work
> with some tweaks.  Will search for it.

I also tried it out and it somehow works. But as argued above, I think
it is actually better to maintain this in separate packages, at least if
you start from a clean slate. This way one can do away with all these
icomplete--field-beg accessors too.

>> Related to my Vertico package, I also have the Corfu package, which uses
>> a similar implementation as Vertico, but uses a child frame to display
>> the completion list (Similar to Company-Box, Company-Posframe etc).
>>
>> https://github.com/minad/vertico
>> https://github.com/minad/corfu

Of course I will not hold you back from revamping Icomplete completely.
It is good to have multiple UIs. But you could seriously consider my
packages - I think they are exactly what you may be looking for - a
clean slate (vertical) reimplementation of Ivy/Icomplete, relying only
on the default completion facilities. I am sure you have some good
criticism regarding my code or improvement proposals.

Daniel