bug#72945: 29.4; Org: ox-html: attr_html not supported in source code and fixed-width blocks during HTML export

Since more than a month has gone by, I am creating this issue to ease tracking. This issue was first mentioned in this post: . Details cross-posted below. Unlike example blocks, source code and fixed-width blocks don't support the att

bug#72945: [PATCH 2/2] ox-html: Add support for attr_html in fixed-width blocks

* lisp/ox-html.el (org-html-fixed-width): Handle attr_html in a manner similar to example blocks. TINYCHANGE --- lisp/ox-html.el | 20 +++- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/lisp/ox-html.el b/lisp/ox-html.el index 3e83f02e2..a85b1e6ac 100644 --- a/li

bug#72945: [PATCH 1/2] ox-html: Add support for attr_html for source code blocks

* lisp/ox-html.el (org-html-src-block): Add org-src-container class to any class attributes specified via the attr_html keyword. TINYCHANGE --- lisp/ox-html.el | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/lisp/ox-html.el b/lisp/ox-html.el index 446698758..

bug#72945: 29.4; Org: ox-html: attr_html not supported in source code and fixed-width blocks during HTML export

Eli Zaretskii writes: > Thanks, but why are you posting this here? ox-html.el is part of Org, My reasoning was that Org is a part of Emacs, so debbugs would be appropriate. Or at least, that it would _not be inappropriate_. Perhaps I was mistaken. > and I don't see anything in the above discu

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

I observe 100% CPU usage for several seconds when invoking dired for a directory on one of the remote machines I connect to. This doesn't seem to happen for another host. The connection to the affected host is slower, and on that host the issue is worse when the directory has several symlinks.

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

Eli Zaretskii writes: >> From: "Suhail Singh" >> Date: Thu, 05 Sep 2024 10:24:54 -0400 >> >> >> I observe 100% CPU usage for several seconds when invoking dired for a >> directory on one of the remote machines I connect to. This doesn't see

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

Eli Zaretskii writes: >> The version of `ls' on this host is: >> >> #+begin_quote >> ls (GNU coreutils) 8.32 >> Copyright (C) 2020 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> . >> This is free software: you are free

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

Eli Zaretskii writes: >> Based on =profiler-report=, the following function "chains" consume most of >> the >> CPU: >> - `font-lock-fontify-keywords-region' >> - tramp-sh-file-name-handler >> - tramp-sh-handle-file-truename >> - `tramp-wait-for-regexp' >> - tramp-sh-handle-file-e

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

Michael Albinus writes: >>> Based on =profiler-report=, the following function "chains" consume most of >>> the >>> CPU: >>> - `font-lock-fontify-keywords-region' >>> - tramp-sh-file-name-handler >>> - tramp-sh-handle-file-truename >>> - `tramp-wait-for-regexp' >>> - tramp-sh-han

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

Michael Albinus writes: >>> > 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

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

Eli Zaretskii writes: > I think we should also try to establish how slow is that connection. > How much time does "ping" take? The server doesn't respond to "ping" requests so I cannot test that. There are however more than 14 hops as reported by mtr. How much more I cannot say, unfortunately.

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

Eli Zaretskii writes: > So if it takes 4 to 5 sec to move a 20KB file, then how much stuff > needs to be moved for the Dired listing? What does the below show, if > you run it on that remote machine? > > $ ls -al | wc Given that the contents of the remote directory can be exactly replicated (

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

Eli Zaretskii writes: > Thanks you. So the problem seems to be symlinks, and specifically > symlinks to directories. After sending the penultimate email, and before sending the last (which contained the workaround for modifying `dired-font-lock-keywords' buffer-locally) I ran some more tests, a

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

CPU, unless I'm missing something. > > Also, Suhail Singh says that there's a significant delay when there > are valid symlinks, in which case I don't expect Tramp to issue the > same command 15 times, right? Yes, while there are clearly inefficiencies in cyclic link de

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

Michael Albinus writes: > I believe it would be helpful to suppress these checks via a user > option. And no, the checks shouldn't be suppressed for remote > directories in general, on a fast connection they are valuable. > > I gave it a try, see appended patch. Thank you for sharing

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

Michael Albinus writes: > ;; Symbolic link to a non-directory. > (list dired-re-sym > (list (lambda (end) > - (when-let ((file (dired-file-name-at-point))) > - (let ((truename (ignore-errors (file-truename file > - (and (

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

Michael Albinus writes: >>> ;; Symbolic link to a non-directory. >>> ... >>> + "\\(.+-> ?\\)\\(.+\\)" end t)) >> >> Minor nitpick: given the comment for this section (which seems to >> suggest this only applies to symlinks to non-directories), wouldn't it >> be

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

Eli Zaretskii writes: >> >> Tramp is in a loop, waiting for results from the remote side. I don't >> >> know how to implement this differently. >> > >> > What kind of loop? Can you point me to the code which loops there? >> >> The umbrella function is tramp-send-command. It sends the command to

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

Michael Albinus writes: > Tramp used a non-zero timeout in the past. This was removed some years > ago, I don't remember the reason. The timeout in tramp-accept-process-output was disabled in commit 54ef338ba3670415cf47fabc33a92d4904707c7e . The commit mentions bug#61350 , however, it's not cle

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

Michael Albinus writes: > I'm happy it works stable now, and I'm reluctant to touch it w/o urgent > need. That's why I have used the (sit-for 0.005) solution proposed by > Eli, outside tramp-accept-process-output. Understood; thanks for elaborating. -- Suhail

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

Eli Zaretskii writes: >> If so, isn't there some mechanism to specify a >> continuation that's run once the TRAMP process produces output? Such a >> mechanism shouldn't require a `sit-for' to yield control. > > How would that help? Tramp must still wait for the response to > proceed with what i

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

Michael Albinus writes: > FTR, some years ago (2018?) I tried to use Lisp threads with Tramp. This > experiment failed. OOC, the failure was from hard-to-debug edge cases while trying to get to feature-parity or something else? -- Suhail