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

[Michael Albinus via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> > FWIW, I cannot reproduce this: I tried Dired on a remote host with
>> > which I have connection that is quite slow, and saw neither high CPU
>> > usage nor a significant delay in displaying a Dired buffer.
>>
>> It seems to be related to font-locking, indeed. See variable
>> `dired-font-lock-keywords'. It specifies face recognition running basic
>> file oprtations. For example, ";; Broken Symbolic link" calls
>> `file-truename' and `file-exists-p', while "Symbolic link to a directory"
>> and ";; Symbolic link to a non-directory" invoke `file-truename' and
>> `file-directory-p'.
>
> But font-lock is ON by default, so what I saw also includes this,
> right?

Sure. But we don't know the exact setting of the OP. The connection
could be extremely slow for him, Tramp's cache might be disabled,
whatever. Perhaps it's worth to rerun the test with "emacs -Q".

>> I believe it would be helpful to suppress these checks via a user
>> option.
>
> What's wrong with "M-x font-lock-mode RET"?

You would deactivate all fontifications, not only the ones related to
symlinks.

And you must do this in a hook of the dired buffer, before fontification
happens.

There exist `dired-hide-details-mode', which I don't know. Perhaps
enabling it in time would do the job?

Best regards, Michael.