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

[João Távora]

On Thu, May 27, 2021 at 2:06 AM Dmitry Gutov <dgutov@yandex.ru> wrote:

> >> The downside should be obvious: you waste extra CPU and memory when you
> >> only need some of these values, and not all of them.
> > I don't see why, though.  Isn't the `fields` arg supposed to solve just
> > that problem?  Or am I missing something?
> OK, that was poor reading on my part (missed 'pcase').
> Also, the above piece of code looks awfully similar to a Company backend
> or frontend definition, which you have disparaged on multiple occasions.

[ Uncalled for, right?  Let's keep cool with the animosity and
the vague accusations, stick to the topic. ]

Here, I was referring specifically to your "obvious" objection, which
seemed nonsensical and ended up just being a reading mistake, that's
fine.

As to ways to improve on Juri's idea, I would maybe suggest a generic function
of string and a single field.  Much like in `affixation-function`,
there's no need to ask
the backend the `mapcar`.  To know what a backend implements would
mean asking that generic function for its methods.

And if you want to "mix and match", a generic function with the backend
as its arg and a hierarchy of backends seems the most elegant choice.
So `:resolution-function` wouldn't be written like that at all, the
backend would
write methods for that `completion-resolution` gf.
But that's redesigning way too much and has numerous other implications
and experience tells me it's not going anywhere and we'd not solve
the annotation problem which is the topic here.

João