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

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

On Wed, Jun 2, 2021 at 12:46 AM Dmitry Gutov <dgutov@yandex.ru> wrote:
> > 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 than from this particular addition.

Yes, yes.  Just that this particular addition pulls things in the wrong
direction, in my opinion.

Another pain point in minibuffer is the representation of candidates.
Sometimes they  are strings, sometimes they are lists of strings with
prefixes and suffixes, lots of silly "if consp".  Really should all be slots
in a completion object.   If that object is a string, text properties are a
good choice (but we could even abstract the implementation away,
though it could be slow).

> >> 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?

Yes, but in that case, a dynamic variable is better than repeating
that little md dance.

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

Yes.

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

We're talking about different things. The group function is a property
of the completion table.  Each invocation transforms a completion,
meaning it produces a property of a completion.  An that property could
be stored in the completion, whatever the format.

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

They're related in the sense that one of them doesn't make
sense without the other.  So it's not only in the interest of
typing, I'd say.

-- 
João Távora