GNU bug report logs -
#73046
29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP
Previous Next
Reported by: "Suhail Singh" <suhailsingh247 <at> gmail.com>
Date: Thu, 5 Sep 2024 14:56:01 UTC
Severity: normal
Found in version 29.4
Fixed in version 31.1
Done: Michael Albinus <michael.albinus <at> gmx.de>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Suhail Singh <suhailsingh247 <at> gmail.com> writes:
>>> 2. If we are in parent directory, and soon after pressing RET we invoke
>>> M-x we don't see the minibuffer prompt till after the offending
>>> directory has finished font-locking.
>>>
>>> 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).
>>>
>>> Thoughts?
>>
>> Are 2 and 3 new with this patch, or were they present in the previous
>> code as well?
>
> Present prior to the patch as well.
To be more accurate, 2 was present prior to the patch. 3 was
unobservable, because prior to the patch CPU usage was at 100%
throughout (regardless of invoking M-x and typing some keys or not).
--
Suhail
This bug report was last modified 240 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.