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

[Dmitry Gutov]

On 02.06.2021 02:22, João Távora wrote:

> > Firs of all, you can construct the same composite values you wanted
> > using the current calling convention of the group-function. And then use
> > them the same way.
>
> Indeed.  Indeed that does show that we simplify the code and can keep
> the current calling convention.  But then why should we? Its akwardness
> becomes even clearer there: calling the same function twice in quick
> succession with different second arg for two different types of return value.

I think the awkwardness comes from the general organization of 
minibuffer.el rather that from this particular addition.

> > Whether this results in better minibuffer.el code is debatable: your
> > diff has more additions than deletions, and one rather long line.
>
> Oh sure, that function is slightly more complicated, but if you look at
>
> completion--insert-strings
> completion--insert-horizontal
> completion--insert-vertical
> completion--insert-one-column
> display-completion-list
> minibuffer-completion-help
>
> You'll find they are all simplified.

Yeah, OK, that's a recent change I haven't read yet. But couldn't any of 
these functions fetch the current group-fun based on the minibuffer 
contents and the current global values?

completion-all-sorted-completions and minibuffer-completion-help have 
relevant code which could be extracted into a helper.

A new dynamic var, as you wrote in a later email, is also an option.

> > OTOH, someone in a different codebase might appreciate that the
> > group-function decouples the mapping to group names from the
> > transformations of the items, and thus one can do the latter closer to
> > where the items are printed, instead of having to "thread" the
> > transformed values to their place of use (from where the grouping logic
> > was called).
>
> Exactly, but my proposal doesn't prevent doing this near the
> print locus.

One might do the grouping and the printing at different stages (in 
different functions).

> > Using a text property is a handy workaround, but ideally one shouldn't
> > have to use it.
>
> There's nothing wrong with it? If you see a transformation function as
> a property of a candidate (which it is in reality -- it's given by a fucntion of
> a candidate), then it's something that fits naturally.  If a candidate was
> some non-string object, I doubt that there would be any doubt as to what
> to do here.  But just because it's a string doesn't change things that much.

It's a property (method) of a completion table, isn't it?

The way I see it, we actually combine there two distinct actions 
(grouping and transform), only in the interest of less typing or 
whatever. But as the actions are distinct, it makes sense to be able to 
ask for one or the other.