[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: Wed, 13 Feb 2019 01:55:01 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Thunderbird/65.0

On 12.02.2019 16:19, Stefan Monnier wrote:
See completion--metadata and completion-extra-properties.

But a completion style like `flex` can't affect either of those.
And I expect some people will want to put in their `completion-styles`,
so `flex` should work well for all/most completion tables and all/most
completion-at-point-functions (and calls to completing-read).

On the one hand, yes, but it's the abstraction we already have, and it will allow flex to work properly at least with certain completion tables. Which is a win.

On the other hand, a search for display-sort-function through Emacs's sources seems to indicate that the design is kind of a failure: there are only a couple places that set it to something, and in both cases it's #'identity, meaning "do not re-sort".

So minibuffer.el might want to take a cue from Company and company-transformers, to make this universal, we could add sorting as a feature of completion styles, or as a separate user option, for maximum flexibility. I'd simply like to avoid hardcoding extra sorting behavior, like the patch proposes.

I think I agree here: the stability of the `flex` sort is likely to make
little difference in practice (more specifically, the sets of matches
which share the same flex-score will be sufficiently numerous and small
that the sorting within them is not significant).


Not sure how that can be done in a modular way: how can we specify an
API where `flex` can provide its scores, `sort-by-occurrence` can
specify its scores, they don't know about each other, and yet the two
sets of scores get mixed in a useful way?

Conveying information via text properties seems like a viable approach. We already use them to indicate matching characters, for instance.

Now, I wouldn't say it's terrible that sort-by-occurrence-and-score would know specifically about flex (I don't think there's going to be a lot of different styles in this flavor), but sure, like you proposed in another email, the property can have a neutral name like completion-score.

To emphasize: there won't be a sort-by-occurrence whatever, but a function called, say, sort-by-occurrence-and-score could take both occurrences and flex scores into account.

reply via email to

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