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

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

On Thu, May 27, 2021 at 7:52 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 27.05.2021 17:19, João Távora wrote:

> I was talking about detecting the lack of such support programmatically.
> At the moment we can do that with (null (plist-get ...)). With generic
> functions, one can get that by catching cl-no-applicable-method.

That's the "poor man's" way to do it.  I don't know if eieio supports
it but CLOS and the AMOP have many more ways to inspect
a generic function.  Anyway, if this is extremely necessary we could add
it to eieio.el.

> I was thinking the definitions in your proposal would look like
>
> (defgeneric im-backend-resolve ((head 'some str) field)
>    <the field is dispatched dynamically on>)
>
> , but the definitions could also look like

That's not how methods on generic functions are
defined, at least not in CLOS, but anyway this is what I mean.

(defmethod im-backend-resolve (str (field (eql 'a-very-interesting field))
  ...
   )

The frontend will call :resolution-function multiple times for the fields
it can layout.  A default method can return nil, or it can signal, or
something else, depending on the API.  (I think returning nil for "I
don't have this field" is the right choice here).

But bear in mind that using generic functions is just one of the backend's
options to implement this.  If backend wants to use regular functions like
Juri suggested, any other dispatching method, it can.  The frontend
has no say on the particular dispatching technique, and that's a good
thing.

This contrasts with the other, more complex and ambitious option,
where the backend adds methods to a generic function that does not
belong to it. That generic functions would have three arguments instead
of two, of course.  If some of those arguments are CLOS classes, the
standard method combinations can do very fancy things in terms
of code reuse.  But I don't recommend this approach now to solve _this_
problem.

> > 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.
> Passing context info through dynamic vars?

They are an implementation detail, but also the easiest way to
establish context. Normally I make them internal, and have
clients read, not write them, via an exported function.  As such,
that function can use any implementation detail it wants.

João