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

[Stefan Monnier]

> See completion--metadata and completion-extra-properties.

But a completion style like `flex` can't affect either of those.
And I expect some people will want to put in their `completion-styles`,
so `flex` should work well for all/most completion tables and all/most
completion-at-point-functions (and calls to completing-read).

> I dunno, sorting takes CPU time anyways. Not sure a combination of several
> sorting functions will frequently give a better result than just one
> of them.

I think I agree here: the stability of the `flex` sort is likely to make
little difference in practice (more specifically, the sets of matches
which share the same flex-score will be sufficiently numerous and small
that the sorting within them is not significant).

> But then, if you enable company-sort-by-occurrence via company-transformers,
> the completion style's sorting won't be visible anymore anyway.

I think this is OK: the front-end can indeed override the
sorting chosen by the completion-style and the completion-table.
If the result is poor, it's the front-end's problem and it is in
a position to fix it.

> It's a question whether any other sorting approaches end up being helpful,
> but maybe some hybrid functions will work, where both occurrences and flex
> score are taken into account.

Not sure how that can be done in a modular way: how can we specify an
API where `flex` can provide its scores, `sort-by-occurrence` can
specify its scores, they don't know about each other, and yet the two
sets of scores get mixed in a useful way?


        Stefan