bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP

[Michael Albinus]

Suhail Singh <suhailsingh247@gmail.com> writes:

Hi Suhail,

> On a related, but distinct note, thoughts on whether there's a
> relatively straightforward way to address "3" below (from one of the
> other exchanges in this thread)?
>
>>> >> 3. If after invoking M-x we immediately start typing, the keyboard input
>>> >>    is registered, however, it doesn't display in the minibuffer till
>>> >>    after the offending directory has finished font-locking.
>>> >>    Additionally, doing so invariably results in 100% CPU usage for the
>>> >>    duration of the font-locking.  Sometimes invoking M-x alone results
>>> >>    in CPU usage going back up to 100% (while font-locking is still being
>>> >>    done).
>>>
>>> > And what do you expect to happen when you press M-x while Emacs is
>>> > still busy performing your previous command?
>>>
>>> I did not expect 3 to happen.  I.e., wrt 3 my expectation was that
>>> invoking M-x and typing doesn't result in a noticable increase in CPU
>>> usage for the duration of the font-locking.
>>
>> If 3 surprised you, then the reason is simple: sit-for returns
>> immediately if any input is available, so typing effectively disables
>> the wait.  This could be countermanded by unconditional sleep, but
>> AFAIU Michael is rethinking the whole issue, so we should wait for him
>> to reach his conclusions.

This would mean to use (sleep-for 0) instead of (sit-for 0), right? Hmm,
I might try the same tests for this clause next days, no idea whether it
makes a difference.

But ATM, we should use (sit-for 0), until we know better.

Best regards, Michael.