[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] scratch/new-flex-completion-style 2c75775 2/2: Score,

From: Dmitry Gutov
Subject: Re: [Emacs-diffs] scratch/new-flex-completion-style 2c75775 2/2: Score, sort and annotate flex-style completions according to match tightness
Date: Thu, 14 Feb 2019 04:33:26 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Thunderbird/65.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]