Re: Possible minibuffer completion enhancements

[Eshel Yaron]

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

> Eshel Yaron <me@eshelyaron.com> writes:
>
>> Daniel Mendler <mail@daniel-mendler.de> writes:
>>>
>>> I try to explain the idea a bit better.

[...20 lines elided...]

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

Right.

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

I agree it may be preferable to let the UI concoct completion predicates,
while my current `narrow-completions-function` proposal puts that weight
on the backend.  For the UI to suggest relevant predicates, it needs
access to relevant completion candidate properties/attributes.  So that
makes sense, thanks.

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

Got it, I think that's worth a try.

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

I think it's a good idea.  In the feature branch I've added a
`narrow-completions-function` to `help--symbol-completion-table`, that
lets you narrow completions to symbols that have some symbol property.
That might be an interesting test case for an alternative approach.  A
challenge, I think, is to cooperate well enough with the UI to not apply
a completion predicate but also clearly communicate that to the user.
With my current `narrow-completions-function`, each predicate that you
get comes with a description (string) that is then shown in the
*Completions* heading line in the default UI.  Users can also use that
description to refer to the predicate if they want to remove it later
with `C-x n w` when there are multiple predicates in place...  Do you
have any thoughts about how this could be achieved alternatively?


Best,

Eshel