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

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

Daniel Mendler <mail@daniel-mendler.de> writes:

> On 5/28/21 12:09 PM, João Távora wrote:
>> Really?  The names of the function mention Company, because at the time
>> company frontend was their only consumer of them, but the point here is
>> to make other frontends consume them.  Anyway, as I understood it they
>> were only examples.
>
> Well, the point here is that these are not annotations, which are not
> meant to be displayed. So what are we talking here about.

Let's see an example: we are talking about elisp--company-doc-string for
'docsig' or elisp--company-location for 'location', to pick two from
Juri's original example.

Both can be displayed, for some meaning of display, it's up to the
frontend to decide _how_ to display it.  In Icomplete:

- 'docsig' could be displayed right-aligned for example, depending on
  available space.

- 'location' could be linkeds to a special keybinding and command that
  would pop a buffer with that location.

Other frontends could do other things with it.  The Company frontend
already has quite specific ways to handle these things, I suppose.

>> That's generally impossible.  How can a frontend know how to display the
>> field 'magical-animated-gif-boomerang-video-url' I'm thinking of
>> attaching to the completions of my completion backend?  Eventually, very
>> fancy frontends will be able to do that, and it's my job to convince
>> them that this is a super-important piece of information to show the
>> user, but some frontends can't or won't show video for example.
>
> It is not impossible as long as we require the annotations to be
> strings. The affixation function also returns strings.

Yes, but this does more than merely affix strings before and after other
strings.  If we insist on "affixation function", we are constraining the
layout from within the backend, and a good design principle is not good
to mix models and presentation ("MCV" design if you're into ~90's
acronyms).

But if you're skeptic, don't take this weak argument of authority,
observes how it really solves our problem here (and many other
problems).

> Alternatively we can specify that the function may return other types
> which are then up to the interpretation of the UI.
>
> There should be a possibility for the UI to request all annotations and
> then it can display the fields it supports.

Why would the UI request annotations for fields it _doesn't_ support?
In that case I have to side with Dmitry, who says it's a waste of
processing.  Why would Icomplete request 'doc-buffer', which is
potentially slow and needs a network request in some backend, if it
doesn't need to show it, or even know how to show it?

> Did you see my submission of the GNU ELPA Marginalia package? The
> package annotates the candidates with multiple annotations which are
> currently displayed in columns. But this formatting happens inside
> Marginalia. It would be great if Marginalia could instead return an
> arbitrary list of annotations which are then formatted by the frontend,
> for example in a table. The list of annotation fields is not fixed.

I don't know Marginalia, sorry.  You want a catch-all for arbitrary
string annotations that some frontends will do their best to display in
a table? If so, in this scheme, make a field called 'lotsa-strings (or
some better name, maybe "marginalia" is a good one).  Then convince
frontends (maybe starting with the ones you control) to give prominence
to that field over other ones.

João