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

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

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

>>> It's worth a try. But if filtering will happen right away after the
>>> user has stopped typing, that might mean higher CPU usage and lower
>>> battery life on a laptop. Just something to be on a lookout for.
>> You're absolutely right.  And anyway I noticed icomplete _already_ has a
>> while-no-input there, so that technique has already been tried.
>
> Not really: the while-no-input was added long after the rest of the code
> was written and was mostly designed for the case where the completion
> data takes a *very* long time to get, the main purpose being to be able
> to enable icomplete for *all* completion tables rather than only for
> those we know to be fast enough.

I don't understand: while-no-input _is_ there, at least it is doing that
which I was going to attempt.  Or do you have some better use of it in
mind that I am not aware of?

Anyway, with the current approach, the problem seems to be that
throw-on-input is not being checked often enough.  I.e in this block:

          (let* (...
                 (text (while-no-input
                         (icomplete-completions
                          field-string
                          (icomplete--completion-table)
                          (icomplete--completion-predicate)
                          (if (window-minibuffer-p)
                              (not minibuffer-completion-confirm)))))
                 (buffer-undo-list t)
                 deactivate-mark)
	    ;; Do nothing if while-no-input was aborted.
            (when (stringp text) ... ))
            
text will often be t, meaning the call _was_ interrupted by
while-no-input, but icomplete-completions was still allowed to run to
completion (and that takes about one or two seconds with empty input).

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:

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index c5d7148..37d1d91 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -3049,7 +3049,9 @@ completion-pcm--all-completions
 	  compl
 	(let ((poss ()))
 	  (dolist (c compl)
-	    (when (string-match-p regex c) (push c poss)))
+	    (when (string-match-p regex c)
+              (input-pending-p)
+              (push c poss)))
 	  (nreverse poss))))))
 
 (defvar flex-score-match-tightness 100
 
If one tries C-h f <some-char> after evaluating this, <some-char>
shows almost immediately after the user typed it.  Now, this is quite
ugly and it still doesn't fix the C-h f RET delay for some reason (but
that shouldn't be very hard to fix, hopefully)

Furthermore, I think the problem pointed to by Dmitry regarding power
consumption is mostly unrelated to this, and targeted effectively by the
existing icomplete-compute-delay variable, which menas battery-wary
users should just set that to a higher value.

João