Re: Possible minibuffer completion enhancements

[Eshel Yaron <me@eshelyaron.com>]

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

> Juri Linkov <juri@linkov.net> 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 tried 'C-x C-v' (minibuffer-sort-completions),
>> and it works nicely.

Great, thanks Juri!

>> But I can't imagine how the whole branch could be merged to master
>> when it contains so diverse set of different features.
>
> I agree. I suggest to create a set of separate patches, e.g., as
> follows:
>
> 1. Helper functions, e.g., completion-table-with-metadata
> 2. CRM refactoring
> 3. Cycle commands for sorting
> 4. Cycle commands for completion styles
> 5. Annotation functions
> 6. Narrowing commands

I'm not sure I understand the use of the word "Cycle" in (3) and (4).
My changes provide new commands that pertain to cycling (`C-o`, `C-l`),
and other commands for sorting (`C-x C-v`) and setting completion styles
(`C-x /`) which are not necessarily related to cycling.  Did you mean to
include "Cycle commands" as a separate bullet, perhaps?

Regarding breaking up the changes into multiple patches, I'm definitely
not opposed, but as I mentioned in another reply, it requires some
effort to do that cleanly.  Would any of you be willing to lend a hand
with that endeavor?  I'd be happy to coordinate, could be a good
opportunity to discuss some of this stuff in more detail as well.

> Regarding 5 and 6 it would be great to explore an alternative approach
> with a :property-function because of the additional flexibility and
> extensibility. We would get a lot of functionality for free.

I think such an approach can leverage the infrastructure that my branch
implements, for example with a `narrow-completions-function` that uses
the properties you get from such a `property-function`, no?  Also, I
agree that the approach you brought up could provide a lot of
functionality, but how would it be more flexible than the proposed
`narrow-completions-function` mechanism, where the completion table can
provide an arbitrary function?

> Iirc Stefan Monnier had plans to change the implementation of the
> completion machinery, rebasing it on a cl-defgeneric mechanism, where
> completion tables provide cl-defmethods. If more and more additional
> completion candidate metadata is supplied, looking into this again may
> be worthwhile.
>
>> For example, probably everyone would agree that
>> 'completion-table-with-metadata' could be installed
>> in master immediately (if you present a separate patch).
>> But other feature might require more discussion.
>
> Indeed. However the implementation of completion-table-with-metadata
> I've seen in Eshel's branch did not seem correct. The function should be
> simpler:

Hmm, define "correct" and "should" :)
My implementation is indeed more sophisticated, since it does more.  In
particular, it lets you override some metadata while preserving other
metadata that come from the original table.  Could you elaborate about
how this simplified version is preferable in your opinion?

> (defun completion-table-with-metadata (table metadata)
>   (lambda (str pred action)
>     (if (eq action 'metadata)
>         `(metadata ,@metadata
>                    ,@(and (functionp table)
>                           (cdr (funcall table str pred action))))
>       (complete-with-action action table str pred))))


Cheers,

Eshel