emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

new-flex-completion-style (was: [Emacs-diffs] scratch/ 2c75775 2/2: Scor


From: Stefan Monnier
Subject: new-flex-completion-style (was: [Emacs-diffs] scratch/ 2c75775 2/2: Score, sort and annotate flex-style completions according to match tightness)
Date: Mon, 11 Feb 2019 16:10:38 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

>     Score, sort and annotate flex-style completions according to match
>     tightness

Sorting is a complicated matter here: we have completion tables,
completion styles, and completion front-ends, and all three seem to want
to be able to sort.

Obviously, the front-end has ultimate control, so we can't stop it from
sorting the way it likes, but we'd like it to be able to make an
informed choice.

As for sorting by the completion table or sorting by the completion
style, it's hard to figure out what should be done in general.
FWIW, it seems that all the completion tables that care about sorting do
it by sorting directly in `all-completions` and then setting the
*-sort-function to `identity`.  Presumably this can only DTRT for "flat"
completion tables.

W.r.t the UI sorting minibuffer.el has 2 different UIs with 2 different
sorting behaviors: there's the *Completions* buffer where results are
sorted alphabetically, and there's the force-complete cycling which
sorts by most-recently seen (using the minibuffer history variable) and
by length.

All this was designed in the context of completion tables and styles
where all returned candidates are basically equally likely.

Flex is going in the direction of completion systems where instead of
splitting the candidates between "possible matches" and "impossible
matches", the matches are all considered as possible, with some more
likely than others.

So in such a context, it's of utmost importance for the completion
table-or-style to provide its own sorting.  And in that case, I guess
most UIs should simply follow that sorting (instead of the current
situation where each UI uses its own sorting).

Still, in a case such as lisp/ecomplete.el where the completion table
provides its own sorting based on recent-usage-frequency, how should
this sorting be combined with that of flex?  I can see arguments in
favor of saying that the flex-weight should be ignored in favor of the
usage-frequency.

>     Up until now, there was no way for completion styles to control
>     sorting.  This change add such a facility and activated it for the new
>     "flex" completion style.

I'd like to move towards a completion-style API that uses cl-generic.
E.g. introduce generic functions like `completion-style-try-completion`
which would be like `completion-try-completion` but takes an additional
`style` argument and dispatches based on it (replacing the dispatch
based on completion-style-alist).

Maybe the sorting code (currently in minibuffer-completion-help) should
be moved to such a generic function, so the completion style would have
the choice of how it uses the `display-sort-function`.  But then should
we do the same with the sorting done in
`completion-all-sorted-completions` or should we come up with a single
generic function that covers both needs?

>     * lisp/minibuffer.el (minibuffer-completion-help): Use
>     completion-style-sort-order and compeltion-style-annotation
                                      ^^^^^^^^^^
                                      completion
>     properties.
>     (completion-pcm--hilit-commonality): Propertize completion with
>     'completion-pcm-commonality-score.
>     (completion-flx-all-completions): Porpertize completion with
                                        ^^^^^^^^^^
                                        Propertize

>     completion-style-sort-order and completion-style-annotation.

Regarding annotations, I think being able to `concat` at the end is
too limited.  If you take your example from sly, we'd like the "15%"
annotations to be right-aligned and I don't see an easy way to do that
with the facility you introduce.

The current annotation facility is also too limited in another way: in
read-char-by-name we annotate each char name with the actual char it
names, but we'd really like to prepend this annotation rather than
append it (it would make the chars much easier to see and to compare),
but the current annotation system doesn't offer this flexibility.

So I'd encourage you to come up with a more flexible annotation system
that allows prepending annotations as well as right-alignment (and
ideally combinations of those, with several columns, ...).


        Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]