Re: Possible minibuffer completion enhancements

[Eshel Yaron <me@eshelyaron.com>]

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

> Eshel Yaron <me@eshelyaron.com> writes:
>
>> Daniel Mendler <mail@daniel-mendler.de> writes:
>>
>>> ...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.

Got it.

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

Thank you for the additional explanation!  I find this approach
appealing, I just think it is not mutually exclusive with my changes:
even if completion tables would provide such a candidate-property
inspection facility, they'd still need to provide also the existing
completion metadata in favor of UIs that currently leverage that, right?
Also the new commands from my branch extend the vanilla completion UI,
and those would remain useful, hopefully, even if we later change how
they obtain the data they need from the backend (completion table).

Anyway, if you or anybody else comes up with a (rough) sketch of this
alternative, I'd be glad to examine it and make a concrete comparison.


Best,

Eshel