emacs-devel
[Top][All Lists]
Advanced

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

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


From: João Távora
Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and, annotations
Date: Wed, 2 Jun 2021 12:04:45 +0100

Wed, Jun 2, 2021 at 11:40 AM Dmitry Gutov <dgutov@yandex.ru> wrote:

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

I don't mind what you call flickering at all, but to each his own,
as usual.

> 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)
> +   ))

Great! i thought it would be more complicated, to be honest.

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

Can you remind us what that delay is doing there again?
Anyway, it should probably consult a customization knob.  Or
maybe the new behaviour could decide based on
icomplete-compute-delay If someone is customizing that to a
low value, turn on the anti-flicker and suffer some little latency.
If the normal value, keep the current flickering and 0-ish latency.

João



reply via email to

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