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

[Dmitry Gutov <dgutov@yandex.ru>]

On 27.05.2021 10:29, João Távora wrote:
> 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. ]

I don't exactly mean to initiate a shouting match here. Someone liking 
(or not) a particular API design can be pertinent, because people are 
going to have to use it, after all.

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

Yup.

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

I don't think this can work without doing the long-discussed migration 
of the completion-table API (or c-a-p-f API) to generic functions.

Upon which we'll lose the capability to mix-and-match using immediate 
values and refer to containing lexical scopes in implementations anyway 
(while gaining in comprehensibility, structure and better code navigation).

Yet still, even when using generic functions, why would we create an 
additional dispatcher mechanism when cl-generic can already do that for 
us? To reduce the number of methods in the API description?

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

Yes, it's orthogonal to the more pressing questions of how information 
returned by 'affixation', etc, should look.