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

[Dmitry Gutov]

On 27.02.2019 19:12, Stefan Monnier wrote:

> I see.  I was taking the point of view of a generic `flex` method for
> use anywhere you like (I think the original motivation was to use it in
> conjunction with `icomplete-mode` to more closely match to `ido`
> behavior).

That's a worthy goal as well, of course. Not sure it will be ideal for 
e.g. eglot's completion table, but that's a separate discussion, I guess.

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

> > > - Add global sorting config var(s?), to choose which kind of sorting to
> > >     use, which would default to sorting based on "scores first and
> > >     alphabetical after that".
> >
> > Put those defaults into completion-category-defaults, and you basically have
> > my proposal, isn't that right?
>
> completion-category-defaults is an alist providing extra settings for
> specific categories, so it's not "global" in the sense I meant above
> because can't be used to choose the sorting used for categories not
> mentioned in completion-category-defaults.

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

I think this will fit the name of the variable, as well as the way it is 
used. The function completion--category-override could use a rename in 
this case, though.

This will also let us set the completion style defaults for the "other" 
categories (and the user too, if completion-category-overrides supports 
the same).

> display-sort is the sorting used when displaying the candidates in
> a list like *Completions* whereas cycle-sort is the sorting used when
> your TAB cycles through possible candidates (and it's also used in
> icomplete-mode).

I see, thanks.

> In display-sort we currently sort alphabetically whereas in cycle-sort
> we want to use a heuristic that puts more likely choices first.
>
> Maybe we should drop this distinction and just use the same sorting
> everywhere (which would have to be the cycle-sort by default I think,
> because the alphabetical sort is really a poor choice when cycling in
> my experience).

Yeah, I do believe we'd prefer the most likely choices at the top in the 
display-sort case as well (or for company-capf, at least).

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