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

[Stefan Monnier]

>>> Also also, combining the flex sorting with most other kinds will most likely
>>> make the flex sorting hard to notice.
>> Depends on the ordering (see below).
> With most helpful/meaningful kinds, then?

With such sorting where most candidates get a different score, it's
difficult to combine the sorting indeed: depending on the precedence we
give to each type of score either the flex sorting will be unnoticeable
or the other one will be unnoticeable.

Of course, if we're careful we can try and tune the weighting of the
types of scores so that both scoring have a visible impact, but I have
the impression that it's going to require too careful tuning to be
usable in practice.

> You mean it can't be used to change settings for the "other" categories, the
> defaults, right? Why don't we use the key 't' for this (with the
> corresponding tiny code change somewhere else)?

Ah, we could yes.  That's equivalent to using another global var, indeed.
Currently we use global vars (completion-styles and
completion-cycle-threshold) for that purpose, mostly by accident.

>> The downside of the heuristic sort of cycle-sort is that sometimes/often
>> the heuristic is poor (by default it's just based on string
>> length ;-( ), so the *Completions* buffer would look "unsorted".
> Improving the heuristics should also help, of course. But it can be left
> for later.

I'm afraid that if we drop the display-sort and use cycle-sort
everywhere, there's going to be a very strong reaction from users not
appreciating the change.  Even more so if the heuristic is poor.


        Stefan