[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: Sat, 5 Jun 2021 04:08:21 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1

On 02.06.2021 18:07, João Távora wrote:
On Wed, Jun 2, 2021 at 3:54 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:

AFAIK it was written under the assumption that the
`icomplete-tidy` call would be automatically "undone" by the
`post-command-hook` before the next redisplay.
Are you okay with the proposed change, then?

I think it's worth a try.

And how do you feel about reducing icomplete-compute-delay to 100ms at most?

For me maybe also not much less than that. For the first few chars, I
usuallly type fast enough, and I appreciate this CPU saving measure.

150ms down from 300ms maybe a good compromise to cut down on the
xx/xx transient inconsistency and still have the CPU saving thing.

OK, so I went ahead with this change.

And also took the liberty of changing icomplete-max-delay-chars to 2: in this day and age, we can certainly deal with longer lists than we could in 1998.

But we can undo either change, of course, upon negative feedback.

Even better, as I suggested, is to make that proposed change be
conditional on the delay.  Then people wanting no flicker just reduce
the delay, which is quite intuitive.

I'm not sure who would want to change the delay to a higher value, and why (people are welcome to tell us).

But even if someone decides to go back to 300 ms, I suspect they would still benefit from the new behavior.

reply via email to

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