emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daniel Mendler
Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and, annotations
Date: Fri, 28 May 2021 18:01:15 +0200

On 5/28/21 4:57 PM, Dmitry Gutov wrote:
> On 28.05.2021 17:10, Daniel Mendler wrote:
> 
>> What about the possibility for the backend to return some kind
>> of description of the available data?
>>
>> (:kind 'icon :keybinding 'string :description 'string ...)
>>
>> But maybe that's also overkill.
> 
> I could get behind something like this. Though it does look like extra 
> work for backend writers.

There is certainly some extra work. On the other hand the backend has to
do a lot of unnecessary formatting which could be pushed to the frontend
layer. The formatting happens for example in Marginalia, which hooks
into the backend completion table.

> My thinking was more along the lines of having the attribute types 
> simply be described in the docs (then only the "known" attributes would 
> be rendered by different frontends), but you and the Marginalia 
> community can probably make a better choice between these options than 
> myself (*).
> 
> Note that this is still compatible with my suggestions of 
> completion-info-columns-function, the latter could still be used for 
> some presentation-level choices (like which columns to display and in 
> which order; but also be able to show arbitrary columns). But it becomes 
> less necessary for sure.
> 
> (*) From where I'm standing, there should be a limited set of columns 
> you'll want to show in such table. Then we could basically document them 
> all at once and forego the introspection capability. But I definitely 
> can be wrong about this.

Yes, this is the difference between the UIs. For vertical
completing-read UIs (default completion with one-column, Vertico, etc)
there is plenty of space to show a lot of helpful information. For
popups this is not the case, there you only want a small set of columns,
which could be hard-coded.

>From my perspective it would be a significant improvement if backends
could add arbitrary fields (with some associated field type, the
frontend can understand or ignore), in contrast to only allowing a fixed
set of fields.

>From what I've seen the Icomplete patch by João is quite independent of
this discussion here and could go in as is. We should probably compare
different prototypes for an enhanced affixation/decoration function to
see how the result could actually look and how well it works in the
different scenarios.

Daniel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]