Re: complexity in minibuffer (was: (icomplete-vertical-mode): Add support for affixations and, annotations)

["João Távora" <joaotavora@gmail.com>]

On Wed, Jun 2, 2021 at 3:19 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I must say I'm not sure what you're referring to here.
> So I went searching for `consp` in minibuffer.el, and IIUC you're
> talking about the code which takes a set of completions and displays it
> in *Completions*.  E.g. the code in `completion--insert-*`.
> Is that right?

Yes (but on only)  And those were the functions who now get an optional
group-fun arg (also often 'if'ed against sometimes only threaded).

> [ If so, it explains why I wasn't sure what you referred to, since it's
>   not part of the code with which I'm familiar ;-)  ]
>
> Indeed, I wonder why we have that.

I think it has to do with the way Juri (or someone else) implemented
affixation function and annotation function, which was what I was trying
to touch to experiment with resolution-function ideas. Sometimes as completion
is represented by a cons (string annotation-prefix annotation-suffix)
sometimes only a string.  It could be a string always, with properties.
Or a struct.  But let's leave it at string and never cons.

> So we could have a quick loop through the completion candidates at the
> entry of `display-completion-list` which converts each candidate to
> a plain string and then calls a streamlined `completion--insert-strings`
> where we don't need those `consp` any more.
> [ And in most cases we could call `completion--insert-strings` directly
>   rather than go through the old `display-completion-list`.  ]
>
> WDYT?  Am I missing something?

Works, but can't we just find we're making the (presumably) useless cons
and just do a propertized string there?   I'd prefer to take a clearer look at
where this messiness was introduced and clean it there.  Which
is commonly why I look at other nearby cleanup opportunities and bring
them up here.  From where I stand this time (code only in master) is when
to strike the iron with the "aesthetics" hammer, which for me normally
translates to "use less code that does the same (and usually quicker)".

João