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

[João Távora]

On Thu, May 27, 2021 at 2:15 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> 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.

Good, then let's not bring up past ones for absolutely no reason.

> I don't think this can work without doing the long-discussed migration

I don't understand this.  I was just suggesting that using a small
variation of Juri's idea, the backend may want to use:

   :resolution-function #'im-backend-x-and-this-is-my-gf

Instead of:

   :resolution-function (lambda (str field) (pcase field ...))

Then, you could easily inspect the methods of
'im-backend-x-and-this-is-my-gf' to see what fields it supports.  The
signature of the gf is:

   (defgeneric im-backend-x-and-this-is-my-gf (str field) ...)

Additionally, and anticipating a possible follow-up question, to share
information between different methods of the same GF (for performance
reasons and only if they indeed exist) one can use a second API point
that is called to let-bind special variables accessed with an argless
function.  I've used this pattern successfully in CLOS many times.

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

We wouldn't.  I _am_ suggesting using cl-generic:

I also tried to express that if we redesigned the method, instead of
'im-backend-x-and-this-is-my-gf', you could have 'this-is-the-resolution-gf'
with a signature that takes the table (aka backend) as an argument:

   (defgeneric this-is-the-resolution-gf (backend field str) ...)

And if backends were CLOS object you could leverage inheritance to mix
and match stuff between different backends.

João