Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico

[Daniel Mendler]

On 4/7/21 6:14 PM, Stefan Monnier wrote:
> > I wonder how all these use cases could be unified under a common
> > API. I would certainly not want to lose the current fast, flat selection
> > mechanism via completion as offered by `completing-read'.
>
> Maybe we could add methods to completion tables that return the set of
> "characteristics" that can be used to filter, others that list the set
> of possible values of those characteristics, etc...

This sounds like a good idea too.

In the context of the Orderless completion style we discussed some 
alternative, which is backward compatible but which bents the definition 
of a completion style a bit. In Orderless each token is used separately 
for filtering and the order of the tokens does not matter, e.g., 
"regexp1 regexp2 regexp3". The idea was to add some special character as 
token prefix to allow filtering by metadata/characteristics, e.g., if 
one filters buffers one could write "@elisp", where the string "elisp" 
is not matched against the candidate string but against some kind of 
metadata string. The metadata would be supplied by an extra function 
registered for the completion category. Your approach is certainly more 
direct.

What I like about the idea of registering such a metadata supplier 
separately is that it allows to enhance completion tables afterwards, 
even if you are not the author of the completion table. There exist a 
few packages enhancing existing completion tables by associating some 
functionality via the completion category:

* Marginalia (https://github.com/minad/marginalia) adds 
annotation/affixation functions
* Embark (https://github.com/oantolin/embark) adds minibuffer actions, 
similar to Ivy actions

But in the context of Emacs itself this approach is probably less 
interesting, maybe except for decoupling some concerns in the code base.