Re: Possible minibuffer completion enhancements

[Daniel Mendler]

Eshel Yaron <me@eshelyaron.com> writes:

> Eshel Yaron <me@eshelyaron.com> writes:
>
>> All right, I've created a new feature branch called
>> feature/minibuffer-completion-enhancements that you can find at:
>>
>> git clone -b feature/minibuffer-completion-enhancements 
>> https://git.sr.ht/~eshel/emacs
>>
>> I've also requested access to push this branch to emacs.git on Savannah,
>> so people won't need to fetch from another Git remote to test it.
>
> 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 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.

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.

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

Daniel