Re: Possible minibuffer completion enhancements

[Daniel Mendler]

Eshel Yaron <me@eshelyaron.com> writes:

> Daniel Mendler <mail@daniel-mendler.de> writes:
>>>> 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).

Absolutely. The changes are not mutually exclusive and the value of the
UI enhancements can be evaluated independently.

Nevertheless I think on the side of the completion table backends we
should explore an approach where the completion tables provides data
only and the UI reuses this data to implement various functions. A few
more points to consider:

1. Changes to completion tables are pervasive, since many completion
   tables will be affected and have to be adapted if we extend them with
   new functionality. We can potentially save complexity if we chose the
   completion table extensions well.
2. If we add metadata extensions with overlapping purpose, e.g., a
   narrowing functions and after that some property function we end up
   with redundant code.
3. If the added functionality to completion tables is generic and not
   too tightly coupled with the UI, new possibilities open up. I had
   mentioned the Orderless completion style which could rely on a
   property-function to implement narrowing by property (not sure if
   this would also work with your narrow function). Also having the
   ability to create sorting functions and annotations from a single
   backend property function seems appealing, if it works.

In your narrow-completions-function proposal, the narrowing
functionality is a UI feature. The narrowing-completions-function even
calls completing-read itself and I think we could do better if we make
sure that the completion tables do not get extended with UI
functionality, but stay lower level, only providing data. In this
respect your narrowing-completions-function differs from existing
metadata extensions, which are lower level and mostly pure
non-interactive functions (for example the annotation-function or
display-sort-function).

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

Sure. However I am not interested in creating competing implementations
which we then compare and ultimately scrap. I'd thought we could maybe
consider a property function as an alternative (lower level, flexible)
completion table extension and if possible, collaborate on such a design
and rebase your UI enhancements on top of that, if you are open to that.
I am not asking you to do all this work or throw yours away. I am rather
asking if you would be interested in helping to explore such an
alternative (for the completion table backends only), or if you think
that a property-function is a flawed idea to begin with.

Daniel