[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: Tue, 12 Feb 2019 03:25:24 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Thunderbird/65.0

On 06.02.2019 22:47, João Távora wrote:

Perhaps I'm missing something, and that is taiting all the remaining
discussion.  Aren't these properties/metadata thingies specific to the
completion table (files, buffers, code completions, etc)?

metadata - yes, properties - no (those are extra elements at the end of the list returned by completion-at-point-functions).

See completion--metadata and completion-extra-properties.

display-sort-function, for now, can only be a metadata element (though that shouldn't be hard to change). annotation-function, however, can be either.

So as things stand, the use of this completion style that'd see in mind, is when a particular completion function returns a table that indicates a particular category (for which the use of flex completion style is enabled), and a particular display-sort-function in its metadata.

Consequently, a preexisting completion tables wouldn't be supported. But like I said, it shouldn't be hard to change either.

In otherwords I should be able to mix and match

- frontends
- completion styles
- backends

Right?  Well all I'm saying is that, when using the flex/scatter
completion style, it's almost always, if not always always, a better
idea to stable-sort by flex-match score.

I dunno, sorting takes CPU time anyways. Not sure a combination of several sorting functions will frequently give a better result than just one of them.

One good way to see this is to try my code with your company.el package,
which doesn't (hopefully _doesn't yet_) use the completion style's
sorting hints.  You can try it in Emacs Lisp. First do:

    (setq completion-styles '(flex))

Now go into the *scratch* buffer and type "undo". You'll see it's not
very useful: the first match you get is ":argument-precedence-order", a
legitimate match, for sure, but you probably meant something related to
the undo facilities.  And you have to scroll quite a bit before you to
"buffer-undo-list", which is buried deep in the many many b's that

But then, if you enable company-sort-by-occurrence via company-transformers, the completion style's sorting won't be visible anymore anyway.

It's a question whether any other sorting approaches end up being helpful, but maybe some hybrid functions will work, where both occurrences and flex score are taken into account.

Eventually, we can add a keybinding to resort exclusively according to
the table or exclusively according to the completion style.

In the approach I'm thinking of, both options are the same sorting function.

And we want "barfoo" to come first.  string-distance talks about
"deletions, insertions and substitutions required to transform a string
into another".  Perhaps if it measured also "move operations" it would
be a better measure.

That's helpful to consider for the actual scores, and sorting.

Then instead of the percentage, we could show just the number of 1-char
editing operations, including moves, to turn the pattern into the
candidate.  That's a measure with actual meaning.

And still, seeing it wouldn't help me if I'm just writing code. Sorry for being blunt.

Sort by them, sure. But show the values to the user? Why?

Even if they do, there's no need to couple this annotation addition to
the completion style. Just use a new annotation function that looks up
the text properties that the style adds, and adds them on.

Again, this would only affect the specific completion table that I'm
writing this function for, right?  Or can I write metadata functions for
completion styles?

The former, more or less. This creates a certain limitation, sure, but it shouldn't be a problem for Eglot.

reply via email to

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