Re: Possible minibuffer completion enhancements

[Eshel Yaron]

Daniel Mendler <mail@daniel-mendler.de> writes:

> Eshel Yaron <me@eshelyaron.com> writes:
>>
>> I've rebased the feature/minibuffer-completion-enhancements branch on
>> top of the current master, and pushed it to emacs.git.  Looking forward
>> for your thoughts and feedback!
>
> Thanks. I took a look at your enhancements

Thank you!

> and I thought one could even go a step further (for the narrowing and
> sorting) by adding a generalized and unified completion candidate
> :property-function.
>
> This function takes a candidate (or a list of candidates as argument)
> and returns a list of properties, characterizing the candidate. For
> files the property function could for example return mode, owner,
> group, size and last modification date. Similarly, for buffers
> possible properties would be the modification status, the size and the
> mode.
>
> Then these properties could be used for:
>
> - Sorting: Add a command to sort the candidates by property field. A
>   comparator function is needed for this to work, maybe based on the
>   property type and cl-defgeneric.
>
> - Annotations: Each of the properties could be displayed in a column
>   view as annotations. A mechanism (again possibly via cl-defgeneric) is
>   needed to transform a property value to its string representation.
>
> - Narrowing/Filtering: A completion style could take the properties and
>   handle a query language with space-separated input, similar to the
>   Orderless completion style, e.g., @mode=lisp. Alternatively a modified
>   minibuffer-completion-predicate could be installed, similar to your
>   narrow-completions-function.

I had similar thoughts while working on some of these things, and I
agree that a standard way for the UI to obtain a set of relevant
properties/attributes of the completion candidates would be an
interesting next step.  My changes already allow you to sort and filter
by properties that are particular to some set of completions candidates
(for example you can sort file completions by last modified time with
`C-x C-v m` in the minibuffer), but a standard way to inspect candidate
attributes would let us provide many more such specialized sorting and
filtering options in many more cases.

> Generally I find it a bit difficult to browse through your changes,
> since they are slightly mixed. There are many ideas here and this may
> make it harder to discuss the changes. Maybe you could reorder the
> commits more logically or create separate branches for separate
> additions.

Are there any parts that you found particularly difficult to review?
Perhaps I could provide more insight.  I've made an effort to provide
some reasoning behind every change in the commit messages, and I also
tried to reorder some commits when I created this branch, but rewriting
history with many overlapping changes proved quite challenging, and I
didn't think it was cost-efficient.

> A few of the changes go in the direction of technical changes unrelated
> to the UI changes, which in my opinion would be good additions:
>
> - completion-table-with-metadata: I've written (or seen) similar helpers
>   many times in packages, so the addition of such helpers would reduce
>   code duplication and simplify completion table construction.

Yes, that's really handy.

>   A while ago I had also proposed an even simpler addition of a
>   completion-table-with-category helper which makes it possible to
>   only override the completion category. This functionality is useful
>   given that one often wants to specify the candidate category, in
>   particular given the recent enhancements by Juri, which added
>   category-based overrides via completion-category-overrides.

Indeed, with `completion-table-with-metadata` this is reduced to:

--8<---------------cut here---------------start------------->8---
(completion-table-with-metadata table '((category . completion-style)))
--8<---------------cut here---------------end--------------->8---

> - The idea to rewrite the CRM functionality looks sound to me. I always
>   wondered why CRM is not going through plain completing-read. Were
>   there specific reasons for the current approach? Maybe Stefan Monnier
>   has some insights on this?

I don't know, I'd appreciate any input from Stefan, of course.


Thanks again for reviewing,

Eshel