[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: João Távora
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, 06 Feb 2019 19:47:13 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (windows-nt)

Dmitry Gutov <address@hidden> writes:

> On 06.02.2019 13:09, João Távora wrote:
>> Perhaps.  But it only does so when the completion style explicitly
>> wanted it.  And even so, the sort order should be stable, i.e. if the
>> completion style puts numerically equal values in two completions, they
>> should retain the backend's order.  And, obviously, it it doesn't put
>> any values in that property, then the backend's order is also retained.
> To put it simply, we already have a way to indicate the completions
> sorting: provide a particular property, or metadata.

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)?

> I'd prefer not to couple completion style with sorting, because
> someone somewhere might prefer to go without it (and use some other
> sorting options, e.g. by frequency of use or mentions in the buffer).

>> In my experience, at least for the "flex" (also called "scatter", by the
>> way) completion style, the frontend's sorting takes precedence
> Not sure what you mean by frontend here.

I meant the completion style.  Though technically the completion style
is a degree short of a frontend, because it is a way to select the
completions collected by the backend (the completion table in Emacs
parlance) and pass them to the graphical frontend, be it icomplete's,
the *Completions* buffer or company.

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.

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

>> It is already customizable: you don't have to use "flex" completion
>> style.  Let's first try it out and then see if we need _more_
>> customization.
> I'd rather we start with the "more simply" alternative I've
> mentioned. But others are welcome to add their opinions.

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

>>> Is this for debugging?
>> At the moment, yes mostly.  But it could not be.  In SLY, I give users
>> an indication of how the scoring algorithm is working.  See it in
>> action:
>> https://raw.githubusercontent.com/joaotavora/sly/master/doc/animations/company-flex-completion.gif
> It's kind of neat, but to be honest I don't see how these percentages
> help a random user.

I can agree they should be improved.  It would be good to integrate some
prior art regarding flex string matching that has a good measure
of the match quality.  The one in the prototype is a empirical thing
that works quite OK for Common Lisp and myself.  `string-distance', for
instance, gives the the Levenshtein distance.  It's got a fancy name,
but it's not very useful for flex completion before

  (string-distance "foo" "barfoo") = (string-distance "foo" "frodos")

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.

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.

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


reply via email to

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