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

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

> I wouldn't worry about that too much, as long as the result is functional.

It'd be OK if it's indispensable, but I think there are better
alternatives that are easy to install right away.

>> I'd rather we extend the infrastructure so that completion styles can do
>> their own sorting.
> That's one option. Another option, which I've mentioned before, is to create
> an indirection for sorting functions via the completion table's
> category.  Similar to the one that completions styles have.

But those are orthogonal: the completion style can offer one kind of
sorting and that should work for all completion tables.
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".
- Let completion-category-overrides specify other choices.

This leaves some questions unanswered, tho:

- What about the distinction between cycle-sort and display-sort?
- 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?).
- Should we allow completion tables to offer several sorting choices?

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.

> The category-based approach should circumvent that problem.
> With this approach, completion styles don't indicate sorting, and whatever
> entity did set up the completion style to be used (the user, a configuration
> package, etc) would need to set up both completion styles and sorting
> functions to match.

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

> I think text properties are fine here.

It has its downsides, but I agree it seems like the better choice.


        Stefan