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 19.02.2019 19:10, Stefan Monnier wrote:
> > > 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.
> > Since we seem to want to redo completion tables in a major way anyway,
>
> That's no guarantee that it will happen soon or at all, and it will have
> to provide some backward compatibility.  And the more hacks we see using
> the current system, the more difficult backward compatibility may become.

Very well.

This may be off topic now, but to the best of my recollection this 
discussion started from the question of the ability to add flex matching 
to particular completion tables. So that's where I was coming from, FWIW.

> But those are orthogonal: the completion style can offer one kind of
> sorting and that should work for all completion tables.

Orthogonal indeed, but it should be easier, implementation-wise, to only 
have one way that defines sorting logic. And also easier to port to the 
"new system", whenever that comes.

Also also, combining the flex sorting with most other kinds will most 
likely make the flex sorting hard to notice.

But please don't take this as a strong disagreement. Just an opinion.

> Completion tables can also offer their own kind of sorting (and it
> should work with all completion styles).
>
> How 'bout:
>
> - 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?

> - Let completion-category-overrides specify other choices.
>
> This leaves some questions unanswered, tho:
>
> - What about the distinction between cycle-sort and display-sort?

TBH, I still don't know what's the difference between these. Meanwhile, 
company-capf has not support for the former, company has different kinds 
of paging through the popup, and it's working okay.

> - Should the new var and new entries in completion-category-overrides
>    contain directly sorting functions, or should they contain just the
>    name of "sorting styles" with a separate table mapping those styles to
>    actual functions (e.g. because a given style like `date` might be
>    implemented differently for different completion tables?).

Erm, I'd try the simpler approach first.

If the tables A and B are supposed to be sorted differently, couldn't 
they return different (but similarly sounding) category names?

Or if that's not generally feasible, what else would the sorting styles 
dispatch on? The tables themselves?

> - Should we allow completion tables to offer several sorting choices?

You mean different completion scores?

If you just mean other kinds of orderings, I think the user will choose 
via completion-category-overrides.

> In any case, in the mean time we can probably just introduce the new
> sorting based on "scores first and alphabetical after that" and use it
> by default.

*thumbsup*

> I think it'd be annoying for users to have to not only add `flex` to
> their completion-styles but also change some sorting option at the same
> time before that completion style becomes usable (in most cases, the
> current alphabetical sorting works really poorly for `flex`).

Apparently you're proposing to fix that by making the default sorting 
function to be flex-compatible. That sounds okay.