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

["João Távora" <joaotavora@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1668 bytes --]

On Mon, Mar 11, 2019, 00:18 Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 27.02.2019 19:12, Stefan Monnier wrote:
>
> > I see.  I was taking the point of view of a generic `flex` method for
> > use anywhere you like (I think the original motivation was to use it in
> > conjunction with `icomplete-mode` to more closely match to `ido`
> > behavior).
>
> That's a worthy goal as well, of course. Not sure it will be ideal for
> e.g. eglot's completion table, but that's a separate discussion, I guess.
>

I've been very busy and just caught up with this discussion. I can't
contribute much more right now other than confirming Stefan's intuition for
the original motivation. I wanted, and want, icomplete to be as usable as
ido.el (with the added advantage of being well behaved). But I also want
eglot.el and elisp's completion-at-point to be able to flex-match like,
i.e. Sly does. So basically I want to be able to flex match everywhere.

Regarding sorting, after using it  in icomplete, C-x b, C-x f, M-x for a
while now, I can say this: There seems to be no case where I wouldn't like
flex's scoring to be the dominant, but I haven't turned it on right now
(mostly because there's no easy way yet due to this analysis-paralysis),
and the table's scoring for those three seems sufficient in a reasonable
number of the situations. When completing larger sets, such as
company-completing all elisp symbols for writing code, flex scoring becomes
indispensable, because the secondary sorting there is lexicographic.

Not sure what you can make of this, but if you can, make something :), and
thanks very much for working on this.

João

[-- Attachment #2: Type: text/html, Size: 2404 bytes --]