Re: Possible minibuffer completion enhancements

[Daniel Mendler]

Eshel Yaron <me@eshelyaron.com> writes:

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

[...]

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

Translating from the low level candidate properties to the UI
presentation is indeed a difficulty. In the case of the
narrow-completions-function the backend and frontend are stronger
coupled, as you say, the function already provides presentation
information.

In the simplest scenario, the UI could present a list of of active
property restrictions (candidate property name and the expected value or
range), to which the user can add and from which the user can delete. If
one wants to go with a more sophisticated approach we could even
introduce a query language. In order to make progress, I'll have to
implement a small prototype as a demonstrator.

The idea to attach more flexible properties has come up a few times
before. When the affixation-function was introduced we had discussed a
decoration-function which specifies multiple fields which are
formatted/aligned by the UI. In contrast, the
annotation-/affixation-function themselves are responsible of
formatting, which puts in my opinion too much burden on the backends. In
an unpublished snippet, I experimented with the addition of properties
for narrowing/restricting the set of candidates. For each candidate
category I defined functions generating a list of properties for
candidates which can then be used for regex-based filtering. In that
case the predicate was build up by parsing a part of the minibuffer
input.

However so far I've not tried to unify the concepts. I'd find it pretty
great if such a more far reaching, unified solution would work out -
presenting candidate properties as annotations, restricting/narrowing by
property, and for sorting by property. I hope this explains my
motivation. A difficulty is certainly to not end up with an
over-engineered solution. I would find it particularly important that
complexity is kept out of the backends.

Daniel