[Top][All Lists]

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

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

From: Daniel Mendler
Subject: Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
Date: Wed, 7 Apr 2021 18:32:59 +0200

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.

reply via email to

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