On 3/28/24 06:44, Ihor Radchenko wrote: >> So I would still suggest that, on Worg, we use my suggested styling >> on #+begin_center blocks. This would make them useful and fulfill >> their natural purpose. > > I think that we have a principal disagreement here. For me, > highlighting #+begin_center blocks is extremely unnatural. I would > never expect that, and I would be extremely surprised by that. It's a mild background color fitting with the theme of the Worg site. And as I've said, centering has not even had any effect up til now. So I don't think it's a big deal. >> Since Worg is updated with relatively low frequency, anyway, >> perhaps this suggestion could be tried as an experiment. If >> problems are found with it, then the extra styling, beyond merely >> centering the text, could be reverted. Nothing is permanent here; >> we've probably spilled more virtual ink on this topic than would be >> affected by the change. > > I am mostly worried about future effect. We will not have any > problems with it in the near future, because the only user of this > style will be your new WORG page. I don't know what there is to worry about. If someone centers some text on a Worg page to make it stand out, it would...stand out? :) >> Anyway, if this idea is vetoed, it would still be good to have some >> way to make text stand out in a standard way, similar to various >> HTML documentation styles in other projects (to avoid resorting to >> inline HTML). It seems like a missing feature on Worg. > > Agree. > >> And the other changes in the patch would be good to have, >> regardless. > > Yup. > I guess we can make this into a poll... (I have no better ideas on > how to resolve the disagreement) I think that's unnecessary. Worg isn't a democracy, after all. If you are vetoing the idea, then let it be vetoed, and let us move on with the rest of the proposed changes. I'll go ahead and push them, without the background color. Thanks, Adam
Visuwesh <visuweshm@gmail.com> writes: > In emacs -Q, try evaluating the source block > > #+BEGIN_SRC calc :var thetarot=1.3 > 1/thetarot > #+END_SRC > > and witness the following error: > > Debugger entered--Lisp error: (wrong-type-argument listp 1.3) > nth(2 1.3) Confirmed. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. ------------------------------------------------------------------------ In emacs -Q, try evaluating the source block #+BEGIN_SRC calc :var thetarot=1.3 1/thetarot #+END_SRC and witness the following error: Debugger entered--Lisp error: (wrong-type-argument listp 1.3) nth(2 1.3) calc-div-fractions(1 1.3) math-div(1 1.3) math-mul-or-div(1 1.3 nil t) math-combine-prod(1 1.3 nil t t) math-simplify-one-divisor((1 1.3) (1.3)) math-simplify-divisor((1 1.3) (1.3) nil t) math-simplify-divide((/ 1 1.3)) #f(compiled-function (expr) #<bytecode -0xce707cc7797ed02>)((/ 1 1.3)) math-simplify-step((/ 1 1.3)) math-simplify((/ 1 1.3)) calc-normalize-fancy((/ 1 1.3)) calc-normalize((/ 1 1.3)) math-evaluate-expr((/ 1 1.3)) #f(compiled-function (line) #<bytecode -0x1da56b5a0e8d9337>)("1/thetarot") mapc(#f(compiled-function (line) #<bytecode -0x1da56b5a0e8d9337>) ("1/thetarot")) org-babel-execute:calc("1/thetarot\11" ((:var thetarot . 1.3) (:colname-names) (:rowname-names) (:result-params "replace") (:result-type . value) (:results . "replace") (:exports . "code") (:session . "none") (:cache . "no") (:noweb . "no") (:hlines . "no") (:tangle . "no"))) org-babel-execute-src-block(nil ("calc" "1/thetarot\11" ((:var thetarot . 1.3) (:colname-names) (:rowname-names) (:result-params "replace") (:result-type . value) (:results . "replace") (:exports . "code") (:tangle . "no") (:hlines . "no") (:noweb . "no") (:cache . "no") (:session . "none")) "" nil 148 "(ref:%s)")) org-ctrl-c-ctrl-c(nil) funcall-interactively(org-ctrl-c-ctrl-c nil) call-interactively(org-ctrl-c-ctrl-c nil nil) command-execute(org-ctrl-c-ctrl-c) This happens because the decimal number 1.3 is not in the format calc expects. A VERY DIRTY patch to do this is diff --git a/lisp/ob-calc.el b/lisp/ob-calc.el index f36df77ff..6ef09032a 100644 --- a/lisp/ob-calc.el +++ b/lisp/ob-calc.el @@ -111,7 +116,7 @@ EL is taken from the output of `math-read-exprs'." (if (and (eq 'var (car el)) (member (cadr el) org--var-syms)) (progn (calc-recall (cadr el)) - (prog1 (calc-top 1) + (prog1 (math-read-exprs (format "%S" (calc-top 1))) (calc-pop 1))) (mapcar #'org-babel-calc-maybe-resolve-var el)) el)) but unfortunately, I don't have the time currently to polish this up. If someone doesn't beat me to it, I will send a more polished+tested patch by the beginning of May (if I get a lot of free time, I can try to make one in the meanwhile). Emacs : GNU Emacs 30.0.50 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo version 1.18.0, Xaw scroll bars) of 2024-02-17 Package: Org mode version 9.7-pre (release_9.6.17-1446-g252971 @ /home/viz/lib/emacs/straight/build/org/)
[-- Attachment #1: Type: text/plain, Size: 1847 bytes --] I have the same problem with lucid. On Thu, 28 Mar 2024 at 11:58, Deric Bytes <dericbytes@gmail.com> wrote: > [Sorry if duplicate, just saw message in last email that I should reply to > All] > > I have a reproducable example. > > - `mouse-autoselect-window' does not make a difference. > - need a tilda in the address > - need to be in full screen > > emacs -q -mm -l test.el > > > (let ((shell-cmd "ls -la") > (output-buffer "my-buf") > (default-directory "/scpx:bangmyhead@192.168.0.46:~") > (process-name "my-proc")) > (start-file-process-shell-command > process-name > (get-buffer-create output-buffer) > shell-cmd) > (switch-to-buffer output-buffer) > (with-current-buffer output-buffer > (goto-char (point-min)) > (find-file-other-window "ooo"))) > > On Thu, 28 Mar 2024 at 11:50, Eli Zaretskii <eliz@gnu.org> wrote: > >> [Please use Reply All to reply, to keep the bug tracker CC'ed.] >> >> > From: Deric Bytes <dericbytes@gmail.com> >> > Date: Thu, 28 Mar 2024 10:55:33 +0000 >> > >> > Eli, I tried with your code and I could not reproduce it. I tried my >> code and could not reproduce it. I tried >> > restarting emacs -q multiple times and I got the problem again whilst >> tweaking but I can not create a case that >> > reproduces every time. >> > >> > I always get it in my main config but that contains so much code and >> the code was written when I was totally >> > clueless and has been causing me problems for ages. I am happy to build >> with something other than GTK and >> > see if that fixes my main emacs config. What do you recommend? >> >> Sorry, I don't know what to recommend. You could try some other >> toolkit, like Lucid, or maybe no toolkit at all. >> >> Martin, any ideas for how to reproduce this, or maybe what could be >> the problem? >> > [-- Attachment #2: Type: text/html, Size: 2837 bytes --]
Michael <sp1ff@runbox.com> writes: > Should we perhaps have different variables for preview & Org > source block evaluation? Likely yes. In fact, ob-latex is making use of `org-preview-latex-process-alist' only in a single cond branch in `org-babel-execute:latex' - when we have :file foo.png However, that branch assumes that `org-preview-latex-default-process' is 'dvipng (the default value). If one changes it to, say dvisvgm, the generated image will not be a .png image: (setq org-preview-latex-default-process 'dvisvgm) #+begin_src latex :results file link :file test.png x^2 #+end_src #+RESULTS: [[attachment:test.png]] ^ This is actually an svg image, renamed to "test.png". So, it makes sense for `org-babel-execute:latex' to override `org-preview-latex-default-process' temporarily, to something actually generating .png file. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
[-- Attachment #1: Type: text/plain, Size: 1188 bytes --] Felician Nemeth <felician.nemeth@gmail.com> writes: > Theodor Thornhill <theo@thornhill.no> writes: > >> This wouldn't help for the usage in find-buffer-visiting, though. But >> this one could more easily be replaced by reworking the diagnostics >> handler. We could store the last received diagnostics in the server >> object, and do a quick lookup from known buffers there. > > eglot-handle-notification:textDocument/publishDiagnostics, > eglot--xref-make-match, and eglot--apply-workspace-edit call > find-buffer-visiting. It seems to me only the first case might be > really time sensitive. Theo, can you email me the relevant messages > that your server sends to Emacs? Does the server send lots of similar > diagnostics messages frequently? > > Thanks, > Felicián I'll try to include such a report a little later today. But yes, it happens a lot. Consider the following patch, though. It eliminates the issues for publishDiagnostics. It can easily be extended to the other places where find-buffer-visiting is used. The publishDiagnostics is sent on change from the server, so that isn't directly initiated by Eglot. What do you think? Theo [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Don-t-use-file-truepath-in-Eglot-bug-70036.patch --] [-- Type: text/x-diff, Size: 5902 bytes --] From d43fe85eae05baa07dd4c3e873a1b94542d97ea9 Mon Sep 17 00:00:00 2001 From: Theodor Thornhill <theo@thornhill.no> Date: Thu, 28 Mar 2024 12:56:23 +0100 Subject: [PATCH] Don't use file-truepath in Eglot (bug#70036) `file-truepath' is slow because of recursive calls and being implemented in lisp. It seems to not be needed in eglot, but it is used behind the scenes in `find-buffer-visiting', thus appearing in profiles. Moving the implementation to a hash map will yield similar performance benefits, but wouldn't require us to rewrite `file-truename' in C. * lisp/progmodes/eglot.el (eglot-lsp-server): Convert 'managed-buffers' to a hashmap. (eglot-uri-to-path): Don't use file-truepath, as it is too slow to be included in the hot path. (eglot--on-shutdown): Use buffers from buffer map. (eglot--managed-mode): Add buffer to map, rather than list. Also remove it from the map on deactivation. (eglot-handle-notification): Expose server and get buffer from the buffer map. --- lisp/progmodes/eglot.el | 30 +++++++++++++++++------------- 1 file changed, 17 insertions(+), 13 deletions(-) diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el index 7d2f1a55165..c6dbca6fc6a 100644 --- a/lisp/progmodes/eglot.el +++ b/lisp/progmodes/eglot.el @@ -1053,8 +1053,8 @@ eglot-lsp-server :documentation "Map (DIR -> (WATCH ID1 ID2...)) for `didChangeWatchedFiles'." :initform (make-hash-table :test #'equal) :accessor eglot--file-watches) (managed-buffers - :initform nil - :documentation "List of buffers managed by server." + :documentation "Map (PATH -> BUFFER) for buffers managed by server." + :initform (make-hash-table :test #'equal) :accessor eglot--managed-buffers) (saved-initargs :documentation "Saved initargs for reconnection purposes." @@ -1085,12 +1085,12 @@ eglot-uri-to-path (defun eglot-path-to-uri (path) "Convert PATH, a file name, to LSP URI string and return it." - (let ((truepath (file-truename path))) + (let ((expanded-path (expand-file-name path))) (if (and (url-type (url-generic-parse-url path)) ;; It might be MS Windows path which includes a drive ;; letter that looks like a URL scheme (bug#59338) (not (and (eq system-type 'windows-nt) - (file-name-absolute-p truepath)))) + (file-name-absolute-p expanded-path)))) ;; Path is already a URI, so forward it to the LSP server ;; untouched. The server should be able to handle it, since ;; it provided this URI to clients in the first place. @@ -1098,11 +1098,11 @@ eglot-path-to-uri (concat "file://" ;; Add a leading "/" for local MS Windows-style paths. (if (and (eq system-type 'windows-nt) - (not (file-remote-p truepath))) + (not (file-remote-p expanded-path))) "/") (url-hexify-string ;; Again watch out for trampy paths. - (directory-file-name (file-local-name truepath)) + (directory-file-name (file-local-name expanded-path)) eglot--uri-path-allowed-chars))))) (defun eglot-range-region (range &optional markers) @@ -1187,7 +1187,7 @@ eglot--servers-by-xrefed-file (defun eglot--on-shutdown (server) "Called by jsonrpc.el when SERVER is already dead." ;; Turn off `eglot--managed-mode' where appropriate. - (dolist (buffer (eglot--managed-buffers server)) + (dolist (buffer (map-values (eglot--managed-buffers server))) (let (;; Avoid duplicate shutdowns (github#389) (eglot-autoshutdown nil)) (eglot--when-live-buffer buffer (eglot--managed-mode-off)))) @@ -1992,7 +1992,11 @@ eglot--managed-mode (add-hook 'eldoc-documentation-functions #'eglot-signature-eldoc-function nil t) (eldoc-mode 1)) - (cl-pushnew (current-buffer) (eglot--managed-buffers (eglot-current-server)))) + + (let ((buffer (current-buffer))) + (puthash (expand-file-name (buffer-file-name buffer)) + buffer + (eglot--managed-buffers (eglot-current-server))))) (t (remove-hook 'after-change-functions #'eglot--after-change t) (remove-hook 'before-change-functions #'eglot--before-change t) @@ -2020,10 +2024,10 @@ eglot--managed-mode (let ((server eglot--cached-server)) (setq eglot--cached-server nil) (when server - (setf (eglot--managed-buffers server) - (delq (current-buffer) (eglot--managed-buffers server))) + (remhash (expand-file-name (buffer-file-name (current-buffer))) + (eglot--managed-buffers server)) (when (and eglot-autoshutdown - (null (eglot--managed-buffers server))) + (null (map-values (eglot--managed-buffers server)))) (eglot-shutdown server))))))) (defun eglot--managed-mode-off () @@ -2346,7 +2350,7 @@ eglot-handle-notification (remhash token (eglot--progress-reporters server)))))))))) (cl-defmethod eglot-handle-notification - (_server (_method (eql textDocument/publishDiagnostics)) &key uri diagnostics + (server (_method (eql textDocument/publishDiagnostics)) &key uri diagnostics &allow-other-keys) ; FIXME: doesn't respect `eglot-strict-mode' "Handle notification publishDiagnostics." (cl-flet ((eglot--diag-type (sev) @@ -2357,7 +2361,7 @@ eglot-handle-notification (mess (source code message) (concat source (and code (format " [%s]" code)) ": " message))) (if-let* ((path (expand-file-name (eglot-uri-to-path uri))) - (buffer (find-buffer-visiting path))) + (buffer (gethash path (eglot--managed-buffers server)))) (with-current-buffer buffer (cl-loop initially -- 2.40.1
[-- Attachment #1: Type: text/plain, Size: 699 bytes --] Adam Porter <adam@alphapapa.net> writes: > On 3/26/24 09:59, Ihor Radchenko wrote: > >> I agree. My concern was not about dropping the previous wording. >> >> What about >> >> The assignment process does not always go quickly; occasionally it may >> get stuck or overlooked at the FSF. If there is no response to the >> contributor from FSF, Org mode maintainers can contact the FSF at >> =copyright-clerk AT fsf DOT org=. Historically, FSF replies to the >> maintainer request within a few days. > ^^^^^^^ > > Other than changing "request" to, e.g. "arrive," no objection from me. Actually, what Bastien suggested is slightly different. See the attached tentative patch. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-org-maintenance.org-Clarify-how-to-followup-when-no-.patch --] [-- Type: text/x-patch, Size: 1477 bytes --] From eff683e8a936edb0e84516daee8d4b8972e3ab8a Mon Sep 17 00:00:00 2001 Message-ID: <eff683e8a936edb0e84516daee8d4b8972e3ab8a.1711627236.git.yantar92@posteo.net> From: Ihor Radchenko <yantar92@posteo.net> Date: Thu, 28 Mar 2024 14:59:40 +0300 Subject: [PATCH] org-maintenance.org: Clarify how to followup when no reply from FSF * org-maintenance.org (Assignment and verification): Explain that we allow one month for FSF to reply for the copyright request and then follow up. Link: https://orgmode.org/list/87o7b3bye3.fsf@localhost --- org-maintenance.org | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/org-maintenance.org b/org-maintenance.org index cfbb55b4..a0393e20 100644 --- a/org-maintenance.org +++ b/org-maintenance.org @@ -467,9 +467,12 @@ *** Assignment and verification #+end_center The assignment process does not always go quickly; occasionally it may -get stuck or overlooked at the FSF. The contact at the FSF for this -is: =copyright-clerk AT fsf DOT org=. In rare cases, an inquiry from an -Org maintainer gets the process moving again. +get stuck or overlooked at the FSF. If there is no response to the +contributor from FSF within a month[fn:: The official response time is +5 business days, according +https://www.gnu.org/prep/maintain/maintain.html. We allow a bit +more.], the maintainers can ask the contributor to follow up with the +FSF, CCing the Org maintainers. *** Authorship information -- 2.44.0 [-- Attachment #3: Type: text/plain, Size: 224 bytes --] -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
[-- Attachment #1: Type: text/plain, Size: 1665 bytes --] [Sorry if duplicate, just saw message in last email that I should reply to All] I have a reproducable example. - `mouse-autoselect-window' does not make a difference. - need a tilda in the address - need to be in full screen emacs -q -mm -l test.el (let ((shell-cmd "ls -la") (output-buffer "my-buf") (default-directory "/scpx:bangmyhead@192.168.0.46:~") (process-name "my-proc")) (start-file-process-shell-command process-name (get-buffer-create output-buffer) shell-cmd) (switch-to-buffer output-buffer) (with-current-buffer output-buffer (goto-char (point-min)) (find-file-other-window "ooo"))) On Thu, 28 Mar 2024 at 11:50, Eli Zaretskii <eliz@gnu.org> wrote: > [Please use Reply All to reply, to keep the bug tracker CC'ed.] > > > From: Deric Bytes <dericbytes@gmail.com> > > Date: Thu, 28 Mar 2024 10:55:33 +0000 > > > > Eli, I tried with your code and I could not reproduce it. I tried my > code and could not reproduce it. I tried > > restarting emacs -q multiple times and I got the problem again whilst > tweaking but I can not create a case that > > reproduces every time. > > > > I always get it in my main config but that contains so much code and the > code was written when I was totally > > clueless and has been causing me problems for ages. I am happy to build > with something other than GTK and > > see if that fixes my main emacs config. What do you recommend? > > Sorry, I don't know what to recommend. You could try some other > toolkit, like Lucid, or maybe no toolkit at all. > > Martin, any ideas for how to reproduce this, or maybe what could be > the problem? > [-- Attachment #2: Type: text/html, Size: 2461 bytes --]
Theodor Thornhill <theo@thornhill.no> writes:
> This wouldn't help for the usage in find-buffer-visiting, though. But
> this one could more easily be replaced by reworking the diagnostics
> handler. We could store the last received diagnostics in the server
> object, and do a quick lookup from known buffers there.
eglot-handle-notification:textDocument/publishDiagnostics,
eglot--xref-make-match, and eglot--apply-workspace-edit call
find-buffer-visiting. It seems to me only the first case might be
really time sensitive. Theo, can you email me the relevant messages
that your server sends to Emacs? Does the server send lots of similar
diagnostics messages frequently?
Thanks,
Felicián
Theodor Thornhill <theo@thornhill.no> writes: > I'm sorry, but I don't see the real difference here. Yes, the profile is > more detailed this way, but it doesn't change the fact that > file-truename is slow, does it? It does not, but it is important for your suggestion to move `file-truename' to the C level. If the slow parts of `file-truename' are the calls to C subroutines, rewriting `file-truename' in C will not help much with the performance. (Unless you try hard and move parts of the used subroutines into the C implementation of `file-truename', but that will involve copy-pasting parts of the existing code and cannot be a good idea without very strong justification) > The question to me is whether or not this is an acceptable performance > hit to take for eglot given what it's trying to do, and my opinion is > no. Whether or not it should be moved to C is open to suggestion. I'm > preparing a patch that only targets Eglot by removing reliance on this > function. If your aim is improving eglot performance specifically, sure. If your aim is improving `file-truename' performance in general, a more detailed analysis can be helpful. > 17839 63% - command-execute > 17794 63% - funcall-interactively > 17793 63% - eval-last-sexp > 17793 63% - #<compiled-function EF0> > 17793 63% - elisp--eval-last-sexp > 17791 63% - eval > 17791 63% - benchmark-call > 17788 63% - #<lambda 219> > 17783 63% - file-truename > 17576 62% - let > ... When you have recursive calls, it is generally more useful to view reversed calltree (B) in the profiler report. It will accumulate calls to the same function together, regardless on how deep in the call stack these calls are made. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
[Please use Reply All to reply, to keep the bug tracker CC'ed.]
> From: Deric Bytes <dericbytes@gmail.com>
> Date: Thu, 28 Mar 2024 10:55:33 +0000
>
> Eli, I tried with your code and I could not reproduce it. I tried my code and could not reproduce it. I tried
> restarting emacs -q multiple times and I got the problem again whilst tweaking but I can not create a case that
> reproduces every time.
>
> I always get it in my main config but that contains so much code and the code was written when I was totally
> clueless and has been causing me problems for ages. I am happy to build with something other than GTK and
> see if that fixes my main emacs config. What do you recommend?
Sorry, I don't know what to recommend. You could try some other
toolkit, like Lucid, or maybe no toolkit at all.
Martin, any ideas for how to reproduce this, or maybe what could be
the problem?
> Date: Thu, 28 Mar 2024 11:45:16 +0100
> From: "Pedro A. Aranda" <paaguti@gmail.com>
>
> Place the following file as init.el in a directory (e.g. ~/.demacs.d)
>
>
> ---- cut here ----
> ;; Mode line settings
>
> (defun server-running-indicator()
> (when (server-running-p) "S "))
> ;; (unless (null server-process) "S "))
>
> ;; (setq-default mode-line-right-align-edge 'right-fringe)
> (setq-default mode-line-format
> (list
> '(:eval (propertize (server-running-indicator)
> 'face 'mode-line-buffer-id))
>
> mode-line-modified
> " "
> mode-line-buffer-identification
> " "
> mode-line-position))
> ---- cut here ----
>
> run emacs as
> /usr/bin/emacs --init-directory ~/.demacs.d
>
> On the emacs window, click on the lower left corner and resize it with
> the mouse. No hangs are observed.
>
> Now, active server-mode with
> M-x server-mode
>
> Try again to resize the emacs window with the mouse. Emacs freezes.
I seem to be unable to reproduce this.
Does the freeze happen only if you resize the frame? What if you just
drag the mode line to resize the window?
And when you say "freezes", does it mean Emacs uses 100% of a CPU's
execution unit, or does it mean it waits for something doing nothing?
Btw, in general, having arbitrary expressions in mode-line's :eval
form might definitely cause problems, since the mode line is called by
redisplay.
Adam Porter <adam@alphapapa.net> writes: > ... > So I would still suggest that, on Worg, we use my suggested styling on > #+begin_center blocks. This would make them useful and fulfill their > natural purpose. I think that we have a principal disagreement here. For me, highlighting #+begin_center blocks is extremely unnatural. I would never expect that, and I would be extremely surprised by that. I guess we can make this into a poll... (I have no better ideas on how to resolve the disagreement) > Since Worg is updated with relatively low frequency, anyway, perhaps > this suggestion could be tried as an experiment. If problems are found > with it, then the extra styling, beyond merely centering the text, could > be reverted. Nothing is permanent here; we've probably spilled more > virtual ink on this topic than would be affected by the change. I am mostly worried about future effect. We will not have any problems with it in the near future, because the only user of this style will be your new WORG page. > Anyway, if this idea is vetoed, it would still be good to have some way > to make text stand out in a standard way, similar to various HTML > documentation styles in other projects (to avoid resorting to inline > HTML). It seems like a missing feature on Worg. Agree. > And the other changes in the patch would be good to have, regardless. Yup. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
On Thu, Mar 28, 2024 at 01:50:37PM +0300, Evgeny Zajcev wrote:
> Yes, this is intentional, because saying "height of the font" in docs, when
> font's pixel size is used in code, is misleading and it took me some time
> to understand why image renders smaller then font height if '(1 . em) is
> specified as dimension modifier. That's why I started using coefficient
> (calculated with `my-em-height-ratio') to `em' specifier
Does this mean we have em wrong? It should ideally, IMO, be equivalent
to em in a web browser because that seems the most common use Emacs
users will be aware of. If we're using the wrong value then we should
change it.
--
Alan Third
Ihor Radchenko <yantar92@posteo.net> writes:
> Theodor Thornhill <theo@thornhill.no> writes:
>
>> Not sure I understand what you mean. I tried it again, but this time the
>> call is 100000 times and in an existing file on my system which is
>> deeply nested. I run emacs with `emacs -Q` from a build on
>> `30b1b0d7cd8e4d46a601e9737350cda970f6bab0`.
>>
>> the relevant part from the profile this time:
>> ```
>> 15478 72% - command-execute
>> 15440 72% - funcall-interactively
>> 15439 72% - eval-last-sexp
>> 15439 72% - #<compiled-function 0C4>
>> 15439 72% - elisp--eval-last-sexp
>> 15436 71% - eval
>> 15436 71% - benchmark-call
>> 15434 71% - #<lambda E8B>
>> 15434 71% - file-truename
>> 13536 63% - file-truename
>> 12224 57% - file-truename
>> ...
>> To me this looks like it spends a lot of time in recursive calls
>
> No. It is just that your `file-truename' is native-compiled and the
> profiler is unable to get the details from inside native subr code.
>
> You can re-evaluate the defun to reveal the details in the profiler
> output. Or use Emacs compiled without native-compilation support.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
I'm sorry, but I don't see the real difference here. Yes, the profile is
more detailed this way, but it doesn't change the fact that
file-truename is slow, does it?
The question to me is whether or not this is an acceptable performance
hit to take for eglot given what it's trying to do, and my opinion is
no. Whether or not it should be moved to C is open to suggestion. I'm
preparing a patch that only targets Eglot by removing reliance on this
function.
Theo
```
17839 63% - command-execute
17794 63% - funcall-interactively
17793 63% - eval-last-sexp
17793 63% - #<compiled-function EF0>
17793 63% - elisp--eval-last-sexp
17791 63% - eval
17791 63% - benchmark-call
17788 63% - #<lambda 219>
17783 63% - file-truename
17576 62% - let
17546 62% - while
17529 62% - let
17358 61% - if
17356 61% - let
16365 58% - or
15969 56% - if
15964 56% - let
15951 56% - file-name-as-directory
15824 56% - file-truename
15788 56% - let
15768 56% - while
15712 55% - let
15579 55% - if
15577 55% - let
7224 25% - or
3429 12% - if
3325 11% - let
3059 10% - file-name-as-directory
1866 6% - file-truename
1501 5% - let
1276 4% - while
1121 3% - let
1004 3% find-file-name-handler
18 0% if
49 0% - setcar
26 0% 1-
37 0% - if
23 0% <
36 0% not
97 0% - if
46 0% - eq
8 0% quote
7 0% or
218 0% - cond
112 0% - and
95 0% - string=
73 0% substring
82 0% - or
57 0% string=
17 0% or
123 0% - setcar
83 0% - cons
```
> From: Vangelis Evangelou <evangelou@gmail.com>
> Date: Thu, 28 Mar 2024 10:35:52 +0000
> Cc: 70046@debbugs.gnu.org
>
> Honestly, I don't know. I'm using XFCE, which is not an unusual window manager. I can try and change some
> settings if you can suggest to diagnose the issue. I believe the ebuffers code has changed recently. It used to
> work without issues in emacs 27 or 28 (I don't remember which).
Maybe Po Lu (CC'ed) could help or have any ideas?
[-- Attachment #1.1: Type: text/plain, Size: 202 bytes --] чт, 28 мар. 2024 г. в 13:50, Evgeny Zajcev <lg.zevlg@gmail.com>: > > Yeah, will send an update soon. > > Here is an update. ChangeLog entry is included in the attached file -- lg [-- Attachment #1.2: Type: text/html, Size: 682 bytes --] [-- Attachment #2: 0001-Add-support-for-ch-and-cw-dimension-specifiers-for-t.patch --] [-- Type: text/x-patch, Size: 3827 bytes --] From 449e860fdec65e92ebca50e99a21afc9ea9c4206 Mon Sep 17 00:00:00 2001 From: Zajcev Evgeny <zevlg@yandex.ru> Date: Thu, 21 Mar 2024 17:47:29 +0300 Subject: [PATCH] Add support for `ch' and `cw' dimension specifiers for the image * src/frame.c (image_get_dimension): Handle `ch' and `cw' dimension specifiers in addition to `em' --- doc/lispref/display.texi | 7 +++++-- src/dispextern.h | 5 +++++ src/image.c | 19 +++++++++++++++++-- 3 files changed, 27 insertions(+), 4 deletions(-) diff --git a/doc/lispref/display.texi b/doc/lispref/display.texi index 4dbb4afb20d..73671a21e7f 100644 --- a/doc/lispref/display.texi +++ b/doc/lispref/display.texi @@ -5788,8 +5788,11 @@ Image Descriptors length in @dfn{ems}@footnote{In typography an em is a distance equivalent to the height of the type. For example when using 12 point type 1 em is equal to 12 points. Its use ensures distances and type -remain proportional.}. One em is equivalent to the height of the font -and @var{value} may be an integer or a float. +remain proportional.}. One em is equivalent to the size of the font +and @var{value} may be an integer or a float. Also, dimension can be +specified in @code{(@var{value} . ch)} and @code{(@var{value} . cw)} +forms, where @code{ch} means height of the canonical character and +@code{cw} means width of the canonical character. The following is a list of properties that are meaningful for all image types (there are also properties which are meaningful only for diff --git a/src/dispextern.h b/src/dispextern.h index 3a4d6095f73..341fb3ac077 100644 --- a/src/dispextern.h +++ b/src/dispextern.h @@ -3176,6 +3176,11 @@ reset_mouse_highlight (Mouse_HLInfo *hlinfo) int face_font_size; char *face_font_family; + /* Details of the font used to calculate image size relative to the + canonical character size, with `ch' and `cw' specifiers. */ + int face_font_height; + int face_font_width; + /* True if this image has a `transparent' background -- that is, is uses an image mask. The accessor macro for this is `IMAGE_BACKGROUND_TRANSPARENT'. */ diff --git a/src/image.c b/src/image.c index 9a465f0b180..244a694a52b 100644 --- a/src/image.c +++ b/src/image.c @@ -2557,9 +2557,20 @@ image_get_dimension (struct image *img, Lisp_Object symbol) if (FIXNATP (value)) return min (XFIXNAT (value), INT_MAX); - if (CONSP (value) && NUMBERP (CAR (value)) && EQ (Qem, CDR (value))) - return scale_image_size (img->face_font_size, 1, XFLOATINT (CAR (value))); + if (CONSP (value) && NUMBERP (CAR (value))) + { + Lisp_Object dim = CDR (value); + if (EQ (Qem, dim)) + return scale_image_size (img->face_font_size, + 1, XFLOATINT (CAR (value))); + if (EQ (Qch, dim)) + return scale_image_size (img->face_font_height, + 1, XFLOATINT (CAR (value))); + if (EQ (Qcw, dim)) + return scale_image_size (img->face_font_width, + 1, XFLOATINT (CAR (value))); + } return -1; } @@ -3383,6 +3394,8 @@ lookup_image (struct frame *f, Lisp_Object spec, int face_id) img->face_foreground = foreground; img->face_background = background; img->face_font_size = font_size; + img->face_font_height = face->font->height; + img->face_font_width = face->font->average_width; img->face_font_family = xmalloc (strlen (font_family) + 1); strcpy (img->face_font_family, font_family); img->load_failed_p = ! img->type->load_img (f, img); @@ -12760,6 +12773,8 @@ syms_of_image (void) DEFSYM (QCmax_height, ":max-height"); DEFSYM (Qem, "em"); + DEFSYM (Qch, "ch"); + DEFSYM (Qcw, "cw"); #ifdef HAVE_NATIVE_TRANSFORMS DEFSYM (Qscale, "scale"); -- 2.25.1
This is tangent to the original problem I described. Max Nikulin <manikulin@gmail.com> writes: > On 25/03/2024 18:18, Ihor Radchenko wrote: >> I am wondering whether it is at all possible to use the same syntax and >> yet pass validation for all the allowed values of `org-html-doctype': >> "html4-strict", "html4-transitional", "html4-frameset", "xhtml-strict", >> "xhtml-transitional", "xhtml-frameset", "xhtml-11", "html5", "xhtml5". > > Is it correct to use text/html for XHTML? I would expect > application/xhtml+xml, but it is better to check standard. It is certainly not an error. Also, https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#texthtml says All HTML content should be served with this type. Alternative MIME types for XHTML (like application/xhtml+xml) are mostly useless nowadays. > For html5 my expectation is > > <meta charset="utf-8"> > > instead of http-equiv > https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta#charset What made you think that your expectation is not fulfilled by ox-html? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
Theodor Thornhill <theo@thornhill.no> writes: > Not sure I understand what you mean. I tried it again, but this time the > call is 100000 times and in an existing file on my system which is > deeply nested. I run emacs with `emacs -Q` from a build on > `30b1b0d7cd8e4d46a601e9737350cda970f6bab0`. > > the relevant part from the profile this time: > ``` > 15478 72% - command-execute > 15440 72% - funcall-interactively > 15439 72% - eval-last-sexp > 15439 72% - #<compiled-function 0C4> > 15439 72% - elisp--eval-last-sexp > 15436 71% - eval > 15436 71% - benchmark-call > 15434 71% - #<lambda E8B> > 15434 71% - file-truename > 13536 63% - file-truename > 12224 57% - file-truename > ... > To me this looks like it spends a lot of time in recursive calls No. It is just that your `file-truename' is native-compiled and the profiler is unable to get the details from inside native subr code. You can re-evaluate the defun to reveal the details in the profiler output. Or use Emacs compiled without native-compilation support. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
Eli Zaretskii <eliz@gnu.org> writes:
> Then maybe Po Lu (CC'ed) could look into this and see if
> pixel-scroll-precision-mode could do better in this case.
Thanks. I think a solution to the OP's problem was proposed in a
previous bug report and we're still awaiting feedback, though at the
moment I don't have its bug number at hand.
Ihor Radchenko <yantar92@posteo.net> writes:
> Theodor Thornhill via "Bug reports for GNU Emacs, the Swiss army knife
> of text editors" <bug-gnu-emacs@gnu.org> writes:
>
>> Firstly, I'll show some benchmarks
>>
>> ```
>> ;; Emacs 29 branch
>>
>> (benchmark-run 10000
>> (file-truename "~/Work/some/long/path/to/parse/that/is/very/deep/deep/deep/super/duper/deep/deep.el"))
>> ;; (1.810892642 1 0.051070616)
>> ...
>> Below are the profiles and the patch. On my system I needed to `ln -s
>> lisp/loadup.el .` to make it compile. Not sure if that is due to
>> differences between old and new `file-truename`, or something else.
>
> The profiles look fishy. For example, in emacs-30-before
>
Not sure I understand what you mean. I tried it again, but this time the
call is 100000 times and in an existing file on my system which is
deeply nested. I run emacs with `emacs -Q` from a build on
`30b1b0d7cd8e4d46a601e9737350cda970f6bab0`.
the relevant part from the profile this time:
```
15478 72% - command-execute
15440 72% - funcall-interactively
15439 72% - eval-last-sexp
15439 72% - #<compiled-function 0C4>
15439 72% - elisp--eval-last-sexp
15436 71% - eval
15436 71% - benchmark-call
15434 71% - #<lambda E8B>
15434 71% - file-truename
13536 63% - file-truename
12224 57% - file-truename
10970 51% - file-truename
9673 45% - file-truename
8468 39% - file-truename
7420 34% - file-truename
6374 29% - file-truename
5286 24% - file-truename
4275 19% - file-truename
3313 15% - file-truename
2454 11% - file-truename
1652 7% - file-truename
984 4% - file-truename
376 1% file-truename
1 0% time-since
1 0% execute-extended-command
```
To me this looks like it spends a lot of time in recursive calls
Theo
[-- Attachment #1: Type: text/plain, Size: 4002 bytes --] чт, 28 мар. 2024 г. в 13:06, Eli Zaretskii <eliz@gnu.org>: > > From: Evgeny Zajcev <lg.zevlg@gmail.com> > > Date: Thu, 21 Mar 2024 22:14:51 +0300 > > Cc: emacs-devel@gnu.org > > > > чт, 21 мар. 2024 г. в 19:57, Eli Zaretskii <eliz@gnu.org>: > > > > > From: Evgeny Zajcev <lg.zevlg@gmail.com> > > > Date: Thu, 21 Mar 2024 17:53:09 +0300 > > > > > > With applied patch and image specified as: > > > > > > (list 'image :type 'svg :file "file.svg" :scale 1.0 :ascent 'center > > > :width '(2 . cw) > > > :max-height '(1 . ch)) > > > > ENOPATCH > > > > :)) sorry, here it is > > Thanks. > > Alan, could you please take a look and comment on this? > > I have a couple of minor stylistic comments below. > > > diff --git a/doc/lispref/display.texi b/doc/lispref/display.texi > > index 4dbb4afb20d..73671a21e7f 100644 > > --- a/doc/lispref/display.texi > > +++ b/doc/lispref/display.texi > > @@ -5788,8 +5788,11 @@ Image Descriptors > > length in @dfn{ems}@footnote{In typography an em is a distance > > equivalent to the height of the type. For example when using 12 point > > type 1 em is equal to 12 points. Its use ensures distances and type > > -remain proportional.}. One em is equivalent to the height of the font > > -and @var{value} may be an integer or a float. > > +remain proportional.}. One em is equivalent to the size of the font > > +and @var{value} may be an integer or a float. Also, dimension can be > > Here, you changed the description of "em" from "height of the font" to > "size of the font". Is this intentional, and if so, why it is better > to say "size" here? > Yes, this is intentional, because saying "height of the font" in docs, when font's pixel size is used in code, is misleading and it took me some time to understand why image renders smaller then font height if '(1 . em) is specified as dimension modifier. That's why I started using coefficient (calculated with `my-em-height-ratio') to `em' specifier > > + /* Details of the font used to calculate image size relative to the > > + canonical character size, with `ch' and `cw' specifiers. */ > ^^ > Please leave two spaces after the last sentence of the comment. > noted > + if (CONSP (value) && NUMBERP (CAR (value))) > > + { > > + if (EQ (Qem, CDR (value))) > > + return scale_image_size (img->face_font_size, > > + 1, XFLOATINT (CAR (value))); > > + if (EQ (Qch, CDR (value))) > > + return scale_image_size (img->face_font_height, > > + 1, XFLOATINT (CAR (value))); > > + if (EQ (Qcw, CDR (value))) > > + return scale_image_size (img->face_font_width, > > + 1, XFLOATINT (CAR (value))); > > Minor efficiency comment: it is better to compute CDR(value) just once > and store it in a temporary: > > if (CONSP (value) && NUMBERP (CAR (value))) > { > Lisp_Object dim = CDR (value); > > if (EQ (Qem, dim)) > return scale_image_size (img->face_font_size, > 1, XFLOATINT (CAR (value))); > if (EQ (Qch, dim)) > return scale_image_size (img->face_font_height, > 1, XFLOATINT (CAR (value))); > > Sure, thought about it, but I think the compiler should do such things, value is not volatile. I did not know about compilers that don't do basic optimizations will do etc. (Optimizing compilers will do this automatically, but an > unoptimized build might become a tad faster.) > > Finally, please include a ChangeLog-style commit log message for this > patch; see CONTRIBUTE for how we expect that to be formatted (and you > can use "git log" to see what we do in practice). > Yeah, will send an update soon. Thank you -- lg [-- Attachment #2: Type: text/html, Size: 5885 bytes --]
Place the following file as init.el in a directory (e.g. ~/.demacs.d) ---- cut here ---- ;; Mode line settings (defun server-running-indicator() (when (server-running-p) "S ")) ;; (unless (null server-process) "S ")) ;; (setq-default mode-line-right-align-edge 'right-fringe) (setq-default mode-line-format (list '(:eval (propertize (server-running-indicator) 'face 'mode-line-buffer-id)) mode-line-modified " " mode-line-buffer-identification " " mode-line-position)) ---- cut here ---- run emacs as /usr/bin/emacs --init-directory ~/.demacs.d On the emacs window, click on the lower left corner and resize it with the mouse. No hangs are observed. Now, active server-mode with M-x server-mode Try again to resize the emacs window with the mouse. Emacs freezes. This doesn't happen if you use the commented line (unless (null server-process) "S ")) instead of the (when (server-running-p) "S ")) In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, cairo version 1.16.0) of 2024-03-28 built on ee9499c728de Repository revision: f1fe13ea057237f5426c93876488cb95be86156c Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12201001 System Description: Ubuntu 22.04.4 LTS Configured using: 'configure --prefix=/usr --program-suffix=30 --with-x --with-x-toolkit=gtk3 --with-cairo --with-compress-install --with-modules=yes --with-threads --with-included-regex --with-zlib --with-json --with-rsvg --with-small-ja-dic --with-native-compilation=aot --with-tree-sitter=no 'CFLAGS=-g -O2 -ffile-prefix-map=/home/paag/emacs=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro'' Configured features: CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB Important settings: value of $LC_MONETARY: es_ES.UTF-8 value of $LC_NUMERIC: es_ES.UTF-8 value of $LC_TIME: es_ES.UTF-8 value of $LANG: en_US.UTF-8 value of $XMODIFIERS: @im=ibus locale-coding-system: utf-8-unix Major mode: Fundamental Minor modes in effect: tooltip-mode: t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t blink-cursor-mode: t minibuffer-regexp-mode: t buffer-read-only: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: /usr/share/emacs/site-lisp/latex-cjk-thai/thai-word hides /usr/share/emacs/30.0.50/lisp/language/thai-word Features: (shadow sort mail-extr emacsbug message mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util text-property-search time-date subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd touch-screen tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind inotify dynamic-setting system-font-setting font-render-setting cairo gtk x-toolkit xinput2 x multi-tty move-toolbar make-network-process native-compile emacs) Memory information: ((conses 16 51330 11727) (symbols 48 5230 0) (strings 32 13871 2528) (string-bytes 1 460407) (vectors 16 9073) (vector-slots 8 126676 10197) (floats 8 40 13) (intervals 56 375 16) (buffers 984 11))
[-- Attachment #1: Type: text/plain, Size: 1286 bytes --] By the way, just to add to that, if I press a or b in the mini frame to copy the change to the other buffer, then I no longer have the issue of losing focus after that. On Thu, 28 Mar 2024 at 10:35, Vangelis Evangelou <evangelou@gmail.com> wrote: > Honestly, I don't know. I'm using XFCE, which is not an unusual window > manager. I can try and change some settings if you can suggest to diagnose > the issue. I believe the ebuffers code has changed recently. It used to > work without issues in emacs 27 or 28 (I don't remember which). > > On Thu, 28 Mar 2024 at 10:28, Eli Zaretskii <eliz@gnu.org> wrote: > >> > From: Vangelis Evangelou <evangelou@gmail.com> >> > Date: Thu, 28 Mar 2024 10:08:51 +0000 >> > Cc: 70046@debbugs.gnu.org >> > >> > Because the cursor moves to that buffer and if I press n or p it >> inserts in that buffer. Here is a video >> > demonstrating this >> > >> https://drive.google.com/file/d/1E7ycJJTYuo62MwViGfiYz_tnornMdXkN/view?usp=sharing >> > >> > Also, note in the video that the mini frame goes under the top bar. I >> don't know if that's an emacs issue >> > though. >> >> Then I definitely cannot reproduce this. Could this be because of the >> particular window manager you are using and/or your system-wide >> settings of the window manager? >> > [-- Attachment #2: Type: text/html, Size: 2169 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1005 bytes --] Honestly, I don't know. I'm using XFCE, which is not an unusual window manager. I can try and change some settings if you can suggest to diagnose the issue. I believe the ebuffers code has changed recently. It used to work without issues in emacs 27 or 28 (I don't remember which). On Thu, 28 Mar 2024 at 10:28, Eli Zaretskii <eliz@gnu.org> wrote: > > From: Vangelis Evangelou <evangelou@gmail.com> > > Date: Thu, 28 Mar 2024 10:08:51 +0000 > > Cc: 70046@debbugs.gnu.org > > > > Because the cursor moves to that buffer and if I press n or p it inserts > in that buffer. Here is a video > > demonstrating this > > > https://drive.google.com/file/d/1E7ycJJTYuo62MwViGfiYz_tnornMdXkN/view?usp=sharing > > > > Also, note in the video that the mini frame goes under the top bar. I > don't know if that's an emacs issue > > though. > > Then I definitely cannot reproduce this. Could this be because of the > particular window manager you are using and/or your system-wide > settings of the window manager? > [-- Attachment #2: Type: text/html, Size: 1621 bytes --]