[Top][All Lists]

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

Re: Improvement proposals for `completing-read'

From: Daniel Mendler
Subject: Re: Improvement proposals for `completing-read'
Date: Thu, 8 Apr 2021 10:37:59 +0200

On 4/8/21 12:16 AM, Dmitry Gutov wrote:
On 07.04.2021 14:16, Daniel Mendler wrote:
   .. Proposal 1: Disabling the history
   .. Proposal 2: More efficient sorting
   .. Proposal 3: Sort file names by history
   .. Proposal 4: Add support for `group-function'
   .. Proposal 5: Forbid the null completions for `REQUIRE-MATCH=t'
   .. Proposal 6: Return text properties from `completing-read'
   .. Proposal 7: Allow duplicates and retain object identity
   .. Proposal 8: Completion style optimization of filtering and highlighting
6. would indeed make sense, and I'm not sure why we wouldn't want to have it in the non-selection case. Whatever come makes use of the completed value, could do the stripping of properties.

Often, completing-read's caller can ensure the properties are there, by using something like (assoc-default completed-string collection) at the end. But that only works if the caller is also the provider of the completion table (otherwise it's an "opaque" data structure).

Yes, you can use an alist and this is also what I use in my Consult package when I want to obtain the associated data. But allowing text-properties could simplify some scenarios and it would be more natural when you are doing selection. If you consider proposal 7 (identity/deduplication), retaining the text properties is an automatic outcome.

9. completion tables need to be able to delegate all matching logic to an external process, both filtering and sorting. That's an important case for code completion, where we can take advantage of existing code and its "fuzzy matching" implementations.

This would be neat, but it requires a lot of restructuring of the completion logic. For this reason I am not fond of this idea. But you can achieve something like this with your proposal 10. See what I describe there, regarding Consult async.

I tried to integrate `fzf` once with Consult async, like generating a list outside Emacs, pushing it through `fzf` for fuzzy-filtering and presenting it to the user via completion. But it turned out that most of the external implementations are not good enough for this use case. They don't have an option to open a pipe to update the filtering input for example. I could write my own fuzzy matcher external backend which would work perfectly with async completion. However then I can also just wait for gccemacs :)

10. support for delayed/asynchronous fetching of completions which doesn't interrupt user's typing (it would generally abort the request if user input is detected, but there might be other approaches to that). Again, that's helpful when completions are produces by an external process.

You may want to take a look at my Consult package, specifically the async functionality. I believe that this functionality can easily be provided on top of the current infrastructure, and actually in a nice way.

In Consult I am using closures which hold the asynchronously acquired data. The closure function must accept a single argument, it can either be a string (the new input) or it can be a list of newly obtained candidates.

(There are also a few more arguments which are accepted 'flush and one can potentially extend this and compose the closure functions. But this is a detail.)

If it is a list the closure function must append the new candidates to the already existing ones and return the full list of candidates. The completion table then calls the async closure with either the input or nil when doing all-completions.

Now a single problem remains - if new data is incoming the async data source must somehow inform completion that new candidates are available. In order to do this the async source must trigger the UI for example via icomplete-exhibit/selectrum-exhibit and so on. It would be good to have a common "completion-refresh" entry point for that. In Consult I have to write a tiny bit of integration code for each supported completion system.

But since this proposal is much more complicated than the ones I didn't add something like this here. Small steps first.

Daniel Mendler

reply via email to

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