Re: [Emacs-diffs] master b0e318d 2/2: Score flex-style completions according to match tightness

[João Távora]

On Sun, Mar 17, 2019 at 8:32 PM Dmitry Gutov <address@hidden> wrote:
> I like for it to be clear what is affected by a variable, and what does
> not. Both from its name and its docstring.

Well, for now _nothing_ is affected by that variable. Let's change the
name when that changes.

> "Slow" had been my impression with flx (the third-party package), but
> didn't it come from scoring rather than matching?

No idea.  The slow in flex almost surely _doesn't_ come from the scoring.

> As long as we're using the same approach for constructing the matching
> regexp as ido-flex does, speed should be okay for most uses.

I haven't checked. But I remember either you or Stefan saying that it uses
a regexp similar to pcm's.

> Another thing I'd like to note: with flex completion, RET doesn't select
> the current candidate anymore (working as intended, of course). But it's
> a bit disorienting.

In what situation exactly? Emacs -Q + (setq completion-styles '(flex)) + what?

> > I wonder
> > if ditching pcm's regexp based approach and coding something by
> > hand (perhaps in C) would be faster.  I haven't done any
> > measurements but the thing feels slow to me: so I wish more
> > people could experiment with it (and with company, too)
>
> ...although it does feel a bit slower than the prefix matching. Maybe
> that's just to be expected.

You're right, more or less, at least judging from some benchmarks:

(benchmark-run-compiled 100
  (let ((completion-styles '(flex)))
    (completion-all-completions "kill" obarray nil 0))) ; => 4.76s

(benchmark-run-compiled 100
  (let ((completion-styles '(basic)))
    (completion-all-completions "kill" obarray nil 0))) ; => 3.7s

... and the first returns a much larger list.

I was expecting to see much larger differences, though, since my
icomplete and company-based experience is really sluggish. But
I wasn't using these much for the default completion style anyway.
Or maybe the sluggishness is coming from somewhere else.

Anyway, as I predicted, most of the work is the matching in
completion-pcm--all-completions.  I'll try to hack something
there when the pattern has some simple flex-like form.

João