Re: Possible minibuffer completion enhancements

[Daniel Mendler]

Eshel Yaron <me@eshelyaron.com> writes:

> Daniel Mendler <mail@daniel-mendler.de> writes:
>
>> Juri Linkov <juri@linkov.net> writes:
>> 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?

I assumed that you also provide commands to cycle between sort functions
and completion styles, instead of selection commands only. Iirc Icicles
provides such commands to cycle between various modes. Replace "Cycle
commands" with "Select and/or cycle commands" above.

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

You are right that a narrow-completions-function could offer narrowing
by property, and itself access the properties via a property-function.
However a property-function is more generic since it will allow us to
build more functionality in to the frontend without further extending
the completion tables.

I try to explain the idea a bit better. Instead of providing an
annotation-function, a display-sort-function, a
narrow-completions-function, a completion table could only provide a
lower level property-function which provides metadata for each
candidate. The completion tables would not have to provide the other
functions anymore.

The UI can query the properties of each candidate and format
annotations, offer sorting and narrowing by properties. This leads to a
separation of data backend (completion table) and presentation by the
UI. The completion table itself is only responsible to provide the data
(candidates and its properties), while the UI is responsible for
presentation features, e.g., sorting or formatting and aligning the
properties as annotations, etc.

This means that a large fraction of the functionality will be part of
the UI and has to be implemented there only once. The completion tables
itself would be reduced to data backends, and we still get annotations,
sorting, narrowing, and possible more property-dependent functionality.

Daniel