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

[Stefan Monnier]

>> FWIW, I think if basic is fast enough and flex is 2x slower, then flex
>> is likely fast enough as well (or the contrapositive: if flex is too
>> slow and basic is only 2x faster, then basic is also too slow).
>
> Hmmm, slightly confused, but I think we're currently in the
> "contrapositive" side (at least given the UI problems that I describe
> below).  Anyway, this is orthogonal, but I do think that flex can be
> made faster so that it is only, say 1.2x, slower than basic in the worst
> case. I'd say it's worth a shot.  Depending on the "basic"
> implementation, it could even be faster.

What I'm saying is that a slowdown of 2x is basically irrelevant here:
it's fast enough (maybe those rare people running on really slow machine
will simply not enable it, but I'm not worried).

> I don't understand: while-no-input _is_ there, at least it is doing that
> which I was going to attempt.

I thought you wanted to replace the icomplete-delay with while-no-input,
rather than just add while-no-input.  Sorry.

> If somehow while-no-input were able to detect interruptions at a more
> finer grained level, I think icomplete-completions would be interrupted
> earlier.  A (dumb) way to fix this is by simply adding a call to
> input-pending-p to one of the critical sections:

If it takes 2s to notice input, maybe it's a bug.  These things depend
on the OS you're running (IIRC we're much less good at it under MacOS),
but it's worth reporting it.


        Stefan