GNU bug report logs - #73046
29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP

Previous Next

Full log

Message #158 received at 73046 <at> debbugs.gnu.org (full text, mbox):

From: Suhail Singh <suhailsingh247 <at> gmail.com>
To: Suhail Singh <suhailsingh247 <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, michael.albinus <at> gmx.de, 73046 <at> debbugs.gnu.org
Subject: Re: bug#73046: 29.4; Emacs 100% CPU usage for several seconds when
 opening dired buffer over TRAMP
Date: Sat, 14 Sep 2024 10:41:49 -0400

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.