emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] master b0e318d 2/2: Score flex-style completions accor


From: Dmitry Gutov
Subject: Re: [Emacs-diffs] master b0e318d 2/2: Score flex-style completions according to match tightness
Date: Sun, 17 Mar 2019 22:32:48 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

On 17.03.2019 21:22, João Távora wrote:

The first line of its docstring also seems misleading.

Re the docstring, you must be refering to the "flex" mention there,
because "Controls how the style scores its matches" is pretty much
what the variable does (and all that can be crammed in columns).

Yes, and the flex in its name.

As I said, when I added this, it was largely open to debate where
scoring would be plugged in.  At that point I thought the style,
particularly the flex style, would be the right spot, but the debate
evolved.  Regardless of making this more general, the flex style
still is the spot where such scoring is needed most urgently, and
I think we should keep it there for a while.

Err, I hope that changes before the release, though.

I like for it to be clear what is affected by a variable, and what does not. Both from its name and its docstring.

Further, purely theoretically, I'm a bit concerned that if we include
scoring at this level, in the common function, it would be harder to
tweak for each individual completion style. But that can be changed
later if we so choose, of course.

A handful of us should eventually start using it first before engaging
in such microtweaks.  I'm more wary of the performance hit that
flex-matching introduces (the matching, not the scoring).

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

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.

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.

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.

I'm all for targeted speed optimizations, of course.



reply via email to

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