[Top][All Lists]

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

Re: Improvement proposals for `completing-read'

From: Dmitry Gutov
Subject: Re: Improvement proposals for `completing-read'
Date: Thu, 8 Apr 2021 01:16:04 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1

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

If you allow me to offer some brief comments and present my own wishlist.

5. would indeed be very nice to have. You can see my current attempt to hack around it in project--completing-read-strict.

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).


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.

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.

reply via email to

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