Re: [Emacs-diffs] scratch/new-flex-completion-style 2c75775 2/2: Score, sort and annotate flex-style completions according to match tightness

[Stefan Monnier]

> On the one hand, yes, but it's the abstraction we already have, and it will
> allow flex to work properly at least with certain completion tables. Which
> is a win.

The problem I see with it is that performing the style-sorting via
completion-metadata or via completion-extra-properties is a hack that
works by breaking abstractions.

So, not only it will only work with some completion tables, but for that
you'll need to introduce "wrong" code in those completion tables.

I'd rather we extend the infrastructure so that completion styles can do
their own sorting.

> On the other hand, a search for display-sort-function through Emacs's
> sources seems to indicate that the design is kind of a failure: there are
> only a couple places that set it to something, and in both cases it's
> #'identity, meaning "do not re-sort".

Indeed.  Those cases *do* perform sorting, but they sort directly inside
their `all-completions` function rather than in their display-sort-function.

So yes, the design is kind of a failure, tho the alternative of having
a boolean in the metadata to say "don't sort" is no simpler.

> So minibuffer.el might want to take a cue from Company and
> company-transformers, to make this universal, we could add sorting as
> a feature of completion styles, or as a separate user option, for maximum
> flexibility.

The question is really: how/where would a completion style specify which
sorting it wants to do (based on the above-mentioned past experience,
we can assume that they'll want to do their sorting directly in
completion-all-completions and then specify "don't sort any further"),
and then how to change minibuffer.el to do that.

Currently, completion-all-completions does not return any information
about which style was used, so either we change this API so that it also
returns which style was used, or some info about the style gets added as
text-properties to influence subsequent sorting, or
completion-all-completions is changed to perform the sorting (which may
require extending its calling convention so the caller can tell it which
kind of sorting it wants).

> Now, I wouldn't say it's terrible that sort-by-occurrence-and-score would
> know specifically about flex (I don't think there's going to be a lot of
> different styles in this flavor), but sure, like you proposed in another
> email, the property can have a neutral name like completion-score.

Using scores would make it possible to combine different scoring systems
by weighting the different parts.  I'm not completely happy with the use
of text-properties, tho (e.g. ideally completion-all-completion could
return a list of pairs of the form (CANDIDATE . SCORE)).  But it has the
very significant advantage of requiring much fewer changes.


        Stefan