Re: Improvement proposals for `completing-read'

[Dmitry Gutov]

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.