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

[Dmitry Gutov <dgutov@yandex.ru>]

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

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.