[Top][All Lists]

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

Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and,

From: Dmitry Gutov
Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and, annotations
Date: Wed, 2 Jun 2021 13:40:51 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1

On 02.06.2021 10:48, João Távora wrote:
Would you rather if "flickered" to "?/?"  ?  Or would
you rather redisplay is inhibited until the totals are known?  Other
completers may use this last option, but I personally dislike sluggish
typing response.

You can try following the recent change in Company for asynchronous backends, where we do redisplay soon after the user typed, briefly showing "outdated" completions with the new input. And then updating it as soon as the new result is computed.

icomplete's implementation is this approach should be a lot easier to do, too. This seems to work okay:

diff --git a/lisp/icomplete.el b/lisp/icomplete.el
index 91bbb60013..29138e089e 100644
--- a/lisp/icomplete.el
+++ b/lisp/icomplete.el
@@ -154,7 +154,8 @@ icomplete--initial-input

 (defun icomplete-pre-command-hook ()
  (let ((non-essential t))
-   (icomplete-tidy)))
+   ;; (icomplete-tidy)
+   ))

 (defun icomplete-post-command-hook ()
   (let ((non-essential t)) ;E.g. don't prompt for password!

I would also suggest lowering the default of icomplete-compute-delay to 0.1 or even 0.05.

With 300ms delay, the new behavior does look a little weird.

And the whole constant updating thing is about
"flickering" anyway.

Experience shows the above is a lot less jarring then hiding all completions ("blinking" with the empty background) and then showing them again.

reply via email to

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