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 13.02.2019 19:00, 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, I 
wouldn't worry about that too much, as long as the result is functional.

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

> So yes, the design is kind of a failure, tho the alternative of having
> a boolean in the metadata to say "don't sort" is no simpler.

It's simpler but more ad-hoc, to be sure.

> The question is really: how/where would a completion style specify which
> sorting it wants to do (based on the above-mentioned past experience,
> we can assume that they'll want to do their sorting directly in
> completion-all-completions and then specify "don't sort any further"),
> and then how to change minibuffer.el to do that.

As we can see from the patch, using text properties (and actually sort 
later) also seems like a viable approach.

> Currently, completion-all-completions does not return any information
> about which style was used, so either we change this API so that it also
> returns which style was used, or some info about the style gets added as
> text-properties to influence subsequent sorting, or
> completion-all-completions is changed to perform the sorting (which may
> require extending its calling convention so the caller can tell it which
> kind of sorting it wants).

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.

> Using scores would make it possible to combine different scoring systems
> by weighting the different parts.  I'm not completely happy with the use
> of text-properties, tho (e.g. ideally completion-all-completion could
> return a list of pairs of the form (CANDIDATE . SCORE)).  But it has the
> very significant advantage of requiring much fewer changes.

I think text properties are fine here. In Company, we use them for 
various bits of information.

Further, if your goal is to combine different scoring systems, it'll 
probably be required to assign different scores (from different systems) 
to each completion. The form (CANDIDATE . SCORE) won't cut it, but text 
properties should.