Re: [BUG] defaults make it hard to edit Elisp blocks in org buffers
Ihor Radchenko writes: If I recall correctly, in order to fix this, in =org-indent-line=, before calling =TAB= in the native buffer, one should check the current line indentation and if it is less than =block-content-ind=, start by adding this much indentation to the current line. This could be a bit fragile, and in particular it assumes that the rest of the block has this =block-content-ind=, which might not be the case. One could possibly at least check that the first line of the block does have this much indentation. If it doesn't, just do whatever. What about a simpler approach - indent the line at point to block's expected indentation (if it is not yet there) and then rely upon the code block's major mode to do the right thing? I cannot think of any common use where the two approches differ, and it is indeed simpler. The possibility that the block does not have the common indentation still stands. -- Sébastien Miquel
Re: [BUG] defaults make it hard to edit Elisp blocks in org buffers
Hi, The issue is that when you press return, you insert a newline, with no indentation, then call =org-indent-line= which edits the block in a native buffer. This is supposed to remove any common indentation, but there is now none. Then it reinserts the code in the org-buffer, adding a new common indentation to the block. If I recall correctly, in order to fix this, in =org-indent-line=, before calling =TAB= in the native buffer, one should check the current line indentation and if it is less than =block-content-ind=, start by adding this much indentation to the current line. This could be a bit fragile, and in particular it assumes that the rest of the block has this =block-content-ind=, which might not be the case. One could possibly at least check that the first line of the block does have this much indentation. If it doesn't, just do whatever. -- Sébastien Miquel
Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]
Ihor Radchenko writes: We should probably reserve the workaround to Emacs 28 and older and eventually remove it when Org drops Emacs 28 support. Ok. I tested using Emacs 28 and 27 and your patch is passing all the tests. Thanks. -- Sébastien Miquel From 6ea37a3041fb3266e94af0bfce29aa76f6c4439d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Fri, 7 Jul 2023 13:58:17 +0200 Subject: [PATCH] test-org-src.el: Work around `current-column' bug in older emacs * testing/lisp/test-org-src.el (test-org-src/indented-blocks): Work around `current-column' not working in the presence of display strings in older emacs. --- testing/lisp/test-org-src.el | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/testing/lisp/test-org-src.el b/testing/lisp/test-org-src.el index a634d85e8..ebf8d8569 100644 --- a/testing/lisp/test-org-src.el +++ b/testing/lisp/test-org-src.el @@ -416,7 +416,13 @@ This is a tab:\t. (let ((org-edit-src-content-indentation 2) (org-src-preserve-indentation nil)) (font-lock-ensure) - (current-column) + ;; `current-column' will not work with older versions of emacs + ;; before commit 4243747b1b8: Fix 'current-column' in the + ;; presence of display strings + (if (<= emacs-major-version 28) + (+ (progn (backward-char) (length (get-text-property (point) 'display))) + (current-column)) + (current-column)) ;; The initial tab characters respect org's `tab-width'. (should (equal @@ -432,7 +438,10 @@ This is a tab:\t. (let ((org-edit-src-content-indentation 2) (org-src-preserve-indentation nil)) (font-lock-ensure) - (current-column)) + (if (<= emacs-major-version 28) + (+ (progn (backward-char) (length (get-text-property (point) 'display))) + (current-column)) + (current-column))) (ert-deftest test-org-src/indented-latex-fragments () "Test editing multiline indented LaTeX fragment." -- 2.41.0
Re: [BUG] org-list-struct-apply-struct overrides src block indentation (was: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)])
Ihor Radchenko writes: The cause is the following line in `org-list-struct-apply-struct' [[file:~/Git/org-mode/lisp/org-list.el::indent-line-to (+ (org-current-text-indentation) delta)))]] It calls `indent-line-to' that replaces spaces with tabs according to current value of indent-tabs-mode in Org buffer. There are a few other instances of `indent-line-to` in the code. I guess the right fix is to un-obsolete `org-indent-line-to`, use it and make a special case if point is in a src block. This use case is uncommon and not really compatible with `org-src-preserve-indentation` though. Somewhat more common possibility: say one has a src block at 0 indentation, and wants to make it part of an org list. Is there any proper org way to do this ? I can use `indent-rigidly`, but again, this might break an org-src indentation. No easy fix to this beside providing a simple org version of `indent-rigidly`. The issues above do not seem too bad. They are uncommon, and an indent-region call should fix the indentation. -- Sébastien Miquel
Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]
Ihor Radchenko writes: Sebastien, it looks like one of the tests is failing on the older Emacs: https://builds.sr.ht/~bzg/job/1020247 Does this specify anywhere what version of emacs it is using ? Most likely, because `current-column' did not take into account 'display property until recently. Here's a workaround. I think I found what emacs commit makes it work, but I haven't been able to test it with an older emacs version. -- Sébastien MiquelFrom 81b33f16ad2e2b2cff20110ff1dafefbc348f9dc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Fri, 7 Jul 2023 13:58:17 +0200 Subject: [PATCH] test-org-src.el: Work around `current-column' bug in older emacs * testing/lisp/test-org-src.el (test-org-src/indented-blocks): Work around `current-column' not working in the presence of display strings in older emacs. --- testing/lisp/test-org-src.el | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/testing/lisp/test-org-src.el b/testing/lisp/test-org-src.el index a634d85e8..5a3af8bb3 100644 --- a/testing/lisp/test-org-src.el +++ b/testing/lisp/test-org-src.el @@ -416,7 +416,11 @@ This is a tab:\t. (let ((org-edit-src-content-indentation 2) (org-src-preserve-indentation nil)) (font-lock-ensure) - (current-column) + ;; Replacement for `current-column', since it doesn't work with + ;; older versions of emacs before commit 4243747b1b8: Fix + ;; 'current-column' in the presence of display strings + (+ (progn (backward-char) (length (get-text-property (point) 'display))) + (current-column)) ;; The initial tab characters respect org's `tab-width'. (should (equal @@ -432,7 +436,8 @@ This is a tab:\t. (let ((org-edit-src-content-indentation 2) (org-src-preserve-indentation nil)) (font-lock-ensure) - (current-column)) + (+ (progn (backward-char) (length (get-text-property (point) 'display))) + (current-column))) (ert-deftest test-org-src/indented-latex-fragments () "Test editing multiline indented LaTeX fragment." -- 2.41.0
Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]
Ihor Radchenko writes: May you now rebase the patch onto the latest main, add a Link: to this discussion to the commit message, and apply the attached extra comments? Here it is. Thanks for helping with this. -- Sébastien MiquelFrom 7906d7b7fa2d376e95156ab7177494f2cececaff Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Tue, 27 Jun 2023 09:23:01 +0200 Subject: [PATCH] org-src.el: Use native value of `indent-tabs-mode' for indentation * lisp/org.el (org-indent-line): Simplify native indentation inside src block. Ensure we add the org indentation if the line is empty. * lisp/org-macs.el (org-do-remove-indentation): Preserve indentation (spaces vs tabs) past the common indentation to remove. Do not empty blank lines. * lisp/org-src.el (org-src--contents-for-write-back): Preserve the native indentation (spaces vs tabs). If necessary, add a common org indentation to the block according to org's `indent-tabs-mode'. (org-src-font-lock-fontify-block): Display the native indentation tab characters with a fixed width, according to the native tab width value, to preserve vertical alignement in the org buffer. * testing/lisp/test-org-src.el (test-org-src/indented-blocks): Update tests. Indentation no longer obeys `indent-tabs-mode' from the org buffer, but is separated in an eventual org part, and the native part. Link: https://list.orgmode.org/87a5wcez7e.fsf@localhost/T/#t --- lisp/org-macs.el | 9 +++-- lisp/org-src.el | 57 --- lisp/org.el | 23 --- testing/lisp/test-org-src.el | 75 ++-- 4 files changed, 94 insertions(+), 70 deletions(-) diff --git a/lisp/org-macs.el b/lisp/org-macs.el index d6879e8cf..aa5c4845e 100644 --- a/lisp/org-macs.el +++ b/lisp/org-macs.el @@ -402,9 +402,12 @@ line. Return nil if it fails." (when skip-fl (forward-line)) (while (not (eobp)) (let ((ind (progn (skip-chars-forward " \t") (current-column - (cond ((eolp) (delete-region (line-beginning-position) (point))) - ((< ind n) (throw :exit nil)) - (t (indent-line-to (- ind n + (cond ((< ind n) + (if (eolp) (delete-region (line-beginning-position) (point)) + (throw :exit nil))) + (t (delete-region (line-beginning-position) +(progn (move-to-column n t) + (point) (forward-line))) ;; Signal success. t diff --git a/lisp/org-src.el b/lisp/org-src.el index 317682844..e1f7d50dc 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -326,9 +326,6 @@ is 0.") "File name associated to Org source buffer, or nil.") (put 'org-src-source-file-name 'permanent-local t) -(defvar-local org-src--preserve-blank-line nil) -(put 'org-src--preserve-blank-line 'permanent-local t) - (defun org-src--construct-edit-buffer-name (org-buffer-name lang) "Construct the buffer name for a source editing buffer. Format is \"*Org Src ORG-BUFFER-NAME[ LANG ]*\"." @@ -481,12 +478,17 @@ Assume point is in the corresponding edit buffer." (list (buffer-substring (point-min) eol) (buffer-substring eol (point-max)) (write-back org-src--allow-write-back) -(preserve-blank-line org-src--preserve-blank-line) -marker) +marker indent-str) +;; Compute the exact sequence of tabs and spaces used to indent up +;; to `indentation-offset' in the Org buffer. +(setq indent-str + (with-temp-buffer +;; Reproduce indentation parameters from org buffer. +(setq indent-tabs-mode use-tabs?) +(when (> source-tab-width 0) (setq tab-width source-tab-width)) +(indent-to indentation-offset) +(buffer-string))) (with-current-buffer write-back-buf - ;; Reproduce indentation parameters from source buffer. - (setq indent-tabs-mode use-tabs?) - (when (> source-tab-width 0) (setq tab-width source-tab-width)) ;; Apply WRITE-BACK function on edit buffer contents. (insert (org-no-properties (car contents))) (setq marker (point-marker)) @@ -496,15 +498,14 @@ Assume point is in the corresponding edit buffer." ;; Add INDENTATION-OFFSET to every line in buffer, ;; unless indentation is meant to be preserved. (when (> indentation-offset 0) - (when preserve-fl (forward-line)) +;; LaTeX-fragments are inline. Do not add indentation to their +;; first line. +(when preserve-fl (forward-line)) (while (not (eobp)) - (skip-chars-forward " \t") - (when (or (not (eolp)) ; not a blank line -(and (eq (point) (marker-position marker)) ; current line - preserve-blank-line)) - (let ((i (current-column))) - (delete-region (line-beginning-position) (point)) -
Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]
Ihor Radchenko writes: For the second scenario, no special treatment of current line is needed. For the first scenario, why do we need to do it all the way in `org-src--contents-for-write-back'? Why not directly in `org-indent-line'? Ah, yes, that is much better. -- Sébastien MiquelFrom 9d31a71bc0ab7cfd466ecad60037d00c62bdd9f6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Tue, 27 Jun 2023 09:23:01 +0200 Subject: [PATCH] org-src.el: Use native value of `indent-tabs-mode' for indentation * lisp/org.el (org-indent-line): Simplify native indentation inside src block. Ensure we add the org indentation if the line is empty. * lisp/org-macs.el (org-do-remove-indentation): Preserve indentation (spaces vs tabs) past the common indentation to remove. Do not empty blank lines. * lisp/org-src.el (org-src--contents-for-write-back): Preserve the native indentation (spaces vs tabs). If necessary, add a common org indentation to the block according to org's `indent-tabs-mode'. (org-src-font-lock-fontify-block): In case of mixed indentation, display the tab characters with a fixed width, according to the native tab width value. * testing/lisp/test-org-src.el (test-org-src/indented-blocks): Update tests. Indentation no longer obeys `indent-tabs-mode' from the org buffer, but is separated in two parts. --- lisp/org-macs.el | 9 +++-- lisp/org-src.el | 52 ++--- lisp/org.el | 23 --- testing/lisp/test-org-src.el | 75 ++-- 4 files changed, 89 insertions(+), 70 deletions(-) diff --git a/lisp/org-macs.el b/lisp/org-macs.el index 51dbfe118..ea210dc60 100644 --- a/lisp/org-macs.el +++ b/lisp/org-macs.el @@ -483,9 +483,12 @@ line. Return nil if it fails." (when skip-fl (forward-line)) (while (not (eobp)) (let ((ind (progn (skip-chars-forward " \t") (current-column - (cond ((eolp) (delete-region (line-beginning-position) (point))) - ((< ind n) (throw :exit nil)) - (t (indent-line-to (- ind n + (cond ((< ind n) + (if (eolp) (delete-region (line-beginning-position) (point)) + (throw :exit nil))) + (t (delete-region (line-beginning-position) +(progn (move-to-column n t) + (point) (forward-line))) ;; Signal success. t diff --git a/lisp/org-src.el b/lisp/org-src.el index f15ba8e99..2beb49e63 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -318,9 +318,6 @@ is 0.") "File name associated to Org source buffer, or nil.") (put 'org-src-source-file-name 'permanent-local t) -(defvar-local org-src--preserve-blank-line nil) -(put 'org-src--preserve-blank-line 'permanent-local t) - (defun org-src--construct-edit-buffer-name (org-buffer-name lang) "Construct the buffer name for a source editing buffer. Format is \"*Org Src ORG-BUFFER-NAME[ LANG ]*\"." @@ -473,12 +470,15 @@ Assume point is in the corresponding edit buffer." (list (buffer-substring (point-min) eol) (buffer-substring eol (point-max)) (write-back org-src--allow-write-back) -(preserve-blank-line org-src--preserve-blank-line) -marker) +marker indent-str) +(setq indent-str + (with-temp-buffer +;; Reproduce indentation parameters from org buffer. +(setq indent-tabs-mode use-tabs?) +(when (> source-tab-width 0) (setq tab-width source-tab-width)) +(indent-to indentation-offset) +(buffer-string))) (with-current-buffer write-back-buf - ;; Reproduce indentation parameters from source buffer. - (setq indent-tabs-mode use-tabs?) - (when (> source-tab-width 0) (setq tab-width source-tab-width)) ;; Apply WRITE-BACK function on edit buffer contents. (insert (org-no-properties (car contents))) (setq marker (point-marker)) @@ -488,15 +488,11 @@ Assume point is in the corresponding edit buffer." ;; Add INDENTATION-OFFSET to every line in buffer, ;; unless indentation is meant to be preserved. (when (> indentation-offset 0) - (when preserve-fl (forward-line)) +;; LaTeX-fragments are inline. Do not add indentation to their +;; first line. +(when preserve-fl (forward-line)) (while (not (eobp)) - (skip-chars-forward " \t") - (when (or (not (eolp)) ; not a blank line -(and (eq (point) (marker-position marker)) ; current line - preserve-blank-line)) - (let ((i (current-column))) - (delete-region (line-beginning-position) (point)) - (indent-to (+ i indentation-offset + (when (not (eolp)) (insert indent-str)) ; not an empty line (forward-line))) (set-marker marker nil @@ -549,11 +545,6 @@ Leave point in edit
Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]
Ihor Radchenko writes: What happens is: in the org buffer, the line is not empty, because it has the org indentation (which was possibly just added by org-indent-line), but in the edit buffer, the line is empty, because the common org indentation was removed. In that case, we want to add back the org indentation. May you please provide an example when it is necessary? `org-indent-line' will run `org-babel-do-key-sequence-in-edit-buffer', so it should still use `org-src--contents-for-write-back' and will not modify the org buffer text directly. You're at the end of a line, you press =org-return-and-indent=. 1. It adds a newline character. 2. =org-indent-line= adds the org indentation, _before_ calling =org-babel-do-key-sequence-in-edit-buffer= 3. The native edit call removes the common indentation, before calling tab in the native buffer. 4. Calling tab in the native buffer possibly does nothing. 5. =org-src--contents-for-write-back= sees the current line is empty, but it should indent it (with org indentation) nonetheless. --- a/lisp/org-macs.el +++ b/lisp/org-macs.el @@ -483,9 +483,12 @@ line. Return nil if it fails." (when skip-fl (forward-line)) (while (not (eobp)) (let ((ind (progn (skip-chars-forward " \t") (current-column - (cond ((eolp) (delete-region (line-beginning-position) (point))) - ((< ind n) (throw :exit nil)) - (t (indent-line-to (- ind n + (cond ((< ind n) + (if (eolp) (delete-region (line-beginning-position) (point)) + (throw :exit nil))) This function is actually confusing both before and after the change. According to the docstring: When optional argument N is a positive integer, remove exactly that much characters from indentation, if possible. But the function can actually remove less than N characters. Before your change, all the blank non-empty lines were unconditionally removed. After your change, the first such line is removed and the function returns nil without continuing. I don't understand. With this change, the function only stops if it finds a non blank line with less than n indentation (same as before). When a blank line with less than n indentation is found, it is emptied (same as before), and execution continues. * lisp/org-macs.el (org-do-remove-indentation): Preserve indentation (spaces vs tabs) past the common indentation to remove. Do not empty blank lines. Since not removing blank lines is intentional after the change, why doing it on a single line that is indented less than N? Are you advocating for computing N using blank lines as well ? 1. It isn't consistent with the previous behaviour. 2. If I mistakenly add a space to an empty line in a src block, an edit-special round trip will add indentation to every line. Is there any benefit ? -- Sébastien Miquel
Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]
Ihor Radchenko writes: + ;; Trim contents: `org-src--contents-for-write-back' may have + ;; added indentation at the beginning, which we remove. May you also mention that we remove the indentation to avoid adding spaces to latex fragments in the middle of a paragraph? On second thought, I don't think moving the LaTeX fragment logic away from `org-src--contents-for-write-back` makes sense. This part of the function does the opposite of `org-do-remove-indentation`, and the latter has a boolean argument `skip-fl`, so it makes sense to keep it the same here. It is simple enough. If you're worried about consistency with inline src blocks, I find it weird for them to have newlines, let alone newlines mixed with org's indentation. But if we do want to treat them the same, then we also need to modify `org-do-remove-indentation` to skip the first line for them as well. I've taken this part off the patch for now. If source code in the edit buffer contains non-empty blank lines, it is not Org's responsibility to clear them. In fact, it will go against possible user settings! So, I agree that we should not indent empty lines. However, I do not agree that we should not indent non-empty blank lines. The patch I propose does indent non-empty blank lines. The issue is with =org-do-remove-indentation= which empties blank lines. I've added a fix to this. -(setq org-src--preserve-blank-line preserve-blank-line) +(setq org-src--indent-current-empty-line (and blank-line + (not empty-line))) Here, you have a variable named "empty-line" set when (not empty-line). ?? I've renamed it yet again! (while (not (eobp)) - (skip-chars-forward " \t") - (when (or (not (eolp)) ; not a blank line -(and (eq (point) (marker-position marker)) ; current line + (when (or (not (eolp)) ; not an empty line +;; If the current line is empty, we may +;; want to indent it. +(and (eq (point) (marker-position marker)) preserve-blank-line)) (insert indent-str)) (forward-line))) removed `skip-chars-forward' call, so the loop will always check every bol and (not (eolp)) will be t for every line, except ^$. Then, considering that preserve-blank-line is set when (not empty-line), your second condition will never trigger. I feel that something is fishy in the logic. What happens is: in the org buffer, the line is not empty, because it has the org indentation (which was possibly just added by org-indent-line), but in the edit buffer, the line is empty, because the common org indentation was removed. In that case, we want to add back the org indentation. -- Sébastien MiquelFrom ecc87b4a75dec7ff8fba4c86635ba3cdb43444ff Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Tue, 27 Jun 2023 09:23:01 +0200 Subject: [PATCH] org-src.el: Use native value of `indent-tabs-mode' for indentation * lisp/org-macs.el (org-do-remove-indentation): Preserve indentation (spaces vs tabs) past the common indentation to remove. Do not empty blank lines. * lisp/org-src.el (org-src--contents-for-write-back): Preserve the native indentation (spaces vs tabs). If necessary, add a common org indentation to the block according to org's `indent-tabs-mode'. (org-src-font-lock-fontify-block): In case of mixed indentation, display the tab characters with a fixed width, according to the native tab width value. * testing/lisp/test-org-src.el (test-org-src/indented-blocks): Update tests. Indentation no longer obeys `indent-tabs-mode' from the org buffer, but is separated in two parts. --- lisp/org-macs.el | 9 +++-- lisp/org-src.el | 45 -- testing/lisp/test-org-src.el | 75 ++-- 3 files changed, 85 insertions(+), 44 deletions(-) diff --git a/lisp/org-macs.el b/lisp/org-macs.el index 51dbfe118..ea210dc60 100644 --- a/lisp/org-macs.el +++ b/lisp/org-macs.el @@ -483,9 +483,12 @@ line. Return nil if it fails." (when skip-fl (forward-line)) (while (not (eobp)) (let ((ind (progn (skip-chars-forward " \t") (current-column - (cond ((eolp) (delete-region (line-beginning-position) (point))) - ((< ind n) (throw :exit nil)) - (t (indent-line-to (- ind n + (cond ((< ind n) + (if (eolp) (delete-region (line-beginning-position) (point)) + (throw :exit nil))) + (t (delete-region (line-beginning-position) +(progn (move-to-column n t) + (point) (forward-line))) ;; Signal success. t diff --git a/lisp/org-src.el b/lisp/org-src.el index f15ba8e99..9e6031016 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -474,11 +474,15 @@ Assume point
Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]
Ihor Radchenko writes: But why do we need to avoid indenting empty lines? In the following link, Greg Minshal argues for preserving empty lines: https://list.orgmode.org/725763.1632663...@apollo2.minshall.org/T/ (CCing the mailing list) -- Sébastien Miquel
Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]
Hi Ihor, Thank you for the feedback. Ihor Radchenko writes: + ;; Apply WRITE-BACK function on edit buffer contents. + (goto-char (point-min)) + (when (functionp write-back) (save-excursion (funcall write-back))) (set-marker marker nil `save-excursion' is no longer necessary here. Done. (defun org-src--edit-element @@ -1150,7 +1149,14 @@ Throw an error when not at such a table." (lambda () ;; Blank lines break things, replace with a single newline. (while (re-search-forward "\n[ \t]*\n" nil t) (replace-match "\n")) -;; If within a table a newline would disrupt the structure, + ;; Trim contents. It would be nice to have a bit more context about the purpose in the comment here. I was confused. We need only trim the beginning of the result, for the indentation added by `org-src--contents-for-write-back'. I've added an explanation. ... - (skip-chars-forward " \t") - (when (or (not (eolp)) ; not a blank line -(and (eq (point) (marker-position marker)) ; current line + (when (or (not (eolp)) ; not an empty line +;; If the current line is empty, we may +;; want to indent it. +(and (eq (point) (marker-position marker)) preserve-blank-line)) Do we still need this dance with special case for current line? Yes. This is fragile, but what it does is, if the line from which the original edit was called was blank and not empty, and the line from which the edit is ended is empty, we assume these two lines are the same, and we add the common block indentation to this empty line. This, and the pre-indentation in =org-indent-line=, make `TAB` work to indent an empty line. The logic in =org-edit-element= can now be simplified though, see the third patch attached. +;; Display tab indentation characters preceded by spaces as spaces +(unless org-src-preserve-indentation unless? Don't we rather want to preserve the original indentation alignment when `org-src-preserve-indentation' is t? + (save-excursion +(goto-char start) +(while (re-search-forward "^[ ]+\\([\t]+\\)" end t) Why just tabs at indentation? It would make sense to preserve width of all the tabs. + (let* ((b (match-beginning 1)) + (e (match-end 1)) + (s (make-string (* (- e b) native-tab-width) ? ))) +(add-text-properties b e `(display ,s)) Will the actual tab width be always equal to native-tab-width? What about tab stops? May it be more reliable to use different of column numbers in the src mode buffer after/before the tab? I was trying to be conservative. When =org-src-preserve-indentation= is t, I guess we can do the same, for consistency. As you say, the tabs at the beginning of indentation are the only ones we can be somewhat sure of the width, if we assume the native indentation was done sanely (using tabs then spaces). I'm inclined to only deal with those. To get the true tab widths, we'd need to get the columns numbers in yet a third different buffer, with the common indentation removed. I don't think that's worth it. Anyway, what I wrote doesn't deal correctly with the case where the org indentation may use tabs. I've updated the patch: I use the value of what should be the org indentation, and only change the display of the following consecutive tabs. @@ -318,19 +318,21 @@ This is a tab:\t. argument2)) #+END_SRC" (setq-local indent-tabs-mode t) - (let ((org-edit-src-content-indentation 2) + (let ((tab-width 8) +(org-edit-src-content-indentation 2) Why is setting tab-width necessary? 8 is the default value. Removed, though I have left an instance of =(setq-local tab-width 8)=, for clarity. #+BEGIN_SRC emacs-lisp -(progn\n (function argument1\n\t\targument2)) +(progn\n (function argument1\n\targument2)) I think it would be a bit more readable to convert this string into actual multi-line, where the alignment is visible when reading the test source. I've left it this way. I think the tests using tab characters are often written this way, so as to be understandable without whitespace mode. -- Sébastien MiquelFrom d024fe96ad889097d025a87dae3316acc44299f6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Sun, 25 Jun 2023 13:38:21 +0200 Subject: [PATCH] org-src--contents-for-write-back: simplify the case of LaTeX fragments * lisp/org-src.el (org-src--contents-for-write-back): Extract special case logic for LaTeX fragments. (org-edit-latex-fragment): Trim the contents to be inserted in the original buffer. --- lisp/org-src.el | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/lisp/org-src.el b/lisp/org-src.el index f15ba8e99..121e59241 100644 --- a/lisp/org-src.el +++
Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]
Ihor Radchenko writes: This is not a problem. We can just apply appropriate 'display property in `org-src-font-lock-fontify-block', manually replacing the tab with appropriate number of spaces (as in the origin buffer). Ok, that works, thanks. Here are two patches, the first that removes the special case logic for LaTeX fragments, and the second that implements what you suggest, and applies on top of the first one. Does that look ok to you ? NB: Calling newline-and-indent from the middle of a line is currently broken, but that has nothing to do with this change. -- Sébastien MiquelFrom d2a86d9011455172e5990149f844031f534e65f2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Sun, 25 Jun 2023 13:38:21 +0200 Subject: [PATCH] org-src--contents-for-write-back: simplify the case of LaTeX fragments * lisp/org-src.el (org-src--contents-for-write-back): Extract special case logic for LaTeX fragments. (org-edit-latex-fragment): Trim the contents to be inserted in the original buffer. --- lisp/org-src.el | 16 +++- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/lisp/org-src.el b/lisp/org-src.el index f15ba8e99..5c272c7f5 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -466,7 +466,6 @@ Assume point is in the corresponding edit buffer." org-src--content-indentation 0 (use-tabs? (and (> org-src--tab-width 0) t)) -(preserve-fl (eq org-src--source-type 'latex-fragment)) (source-tab-width org-src--tab-width) (contents (org-with-wide-buffer (let ((eol (line-end-position))) @@ -479,16 +478,13 @@ Assume point is in the corresponding edit buffer." ;; Reproduce indentation parameters from source buffer. (setq indent-tabs-mode use-tabs?) (when (> source-tab-width 0) (setq tab-width source-tab-width)) - ;; Apply WRITE-BACK function on edit buffer contents. (insert (org-no-properties (car contents))) (setq marker (point-marker)) (insert (org-no-properties (car (cdr contents (goto-char (point-min)) - (when (functionp write-back) (save-excursion (funcall write-back))) ;; Add INDENTATION-OFFSET to every line in buffer, ;; unless indentation is meant to be preserved. (when (> indentation-offset 0) - (when preserve-fl (forward-line)) (while (not (eobp)) (skip-chars-forward " \t") (when (or (not (eolp)) ; not a blank line @@ -498,6 +494,9 @@ Assume point is in the corresponding edit buffer." (delete-region (line-beginning-position) (point)) (indent-to (+ i indentation-offset (forward-line))) + ;; Apply WRITE-BACK function on edit buffer contents. + (goto-char (point-min)) + (when (functionp write-back) (save-excursion (funcall write-back))) (set-marker marker nil (defun org-src--edit-element @@ -1150,7 +1149,14 @@ Throw an error when not at such a table." (lambda () ;; Blank lines break things, replace with a single newline. (while (re-search-forward "\n[ \t]*\n" nil t) (replace-match "\n")) - ;; If within a table a newline would disrupt the structure, + ;; Trim contents. + (goto-char (point-min)) + (skip-chars-forward " \t") + (delete-region (point-min) (point)) + (goto-char (point-max)) + (skip-chars-backward " \t") + (delete-region (point) (point-max)) + ;; If within a table a newline would disrupt the structure, ;; so remove newlines. (goto-char (point-min)) (when (org-element-lineage context '(table-cell)) -- 2.41.0 From ab48e9671efdaba6566f406b1df81a441c72252c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Tue, 27 Jun 2023 09:23:01 +0200 Subject: [PATCH] org-src.el: Use native value of `indent-tabs-mode' for indentation * lisp/org-macs.el (org-do-remove-indentation): Preserve indentation (spaces vs tabs) past the common indentation to remove. * lisp/org-src.el (org-src--contents-for-write-back): Preserve the native indentation (spaces vs tabs). If necessary, add a common org indentation to the block according to org's `indent-tabs-mode'. (org-src-font-lock-fontify-block): In case of mixed indentation, display the tab characters with a fixed width, according to the native tab width value. * testing/lisp/test-org-src.el (test-org-src/indented-blocks): Update tests. Indentation no longer obeys `indent-tabs-mode' from the org buffer, but is separated in two parts. --- lisp/org-macs.el | 4 ++- lisp/org-src.el | 36 ++--- testing/lisp/test-org-src.el | 62 +++- 3 files changed, 60 insertions(+), 42 deletions(-) diff --git a/lisp/org-macs.el b/lisp/org-macs.el index 51dbfe118..f42e6b14b 100644 --- a/lisp/org-macs.el +++ b/lisp/org-macs.el @@ -485,7 +485,9 @@ line. Return nil if it fails." (let ((ind (progn (skip-chars-forward " \t") (current-column (cond
Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]
Ihor Radchenko writes: May you please provide an example for such breakage? From my point of view, alignment is far lesser concern compared to indentation breaking code execution/tangling/other functional parts of Org. Let's say tab-width is 8 and elisp-mode uses tabs for indentation. In the following snippet, arg2 should be indented with a tab. #+BEGIN_SRC emacs-lisp (some-f arg1 arg2) ;; arg2 is indented at column 8 #+END_SRC If I add two spaces at the beginning of the block. It should visually look like this: #+BEGIN_SRC emacs-lisp (some-f arg1 arg2) ;; arg2 is indented at column 8 #+END_SRC Calling =indent-to= would rather put the two spaces after the tab character. But then we lose this idea of clean separation between the org indentation and the native indentation, and we will need to convert the indent of every line on subsequent edits (org -> elisp), as well as for tangling, or code execution. If we have to do this, we might as well just respect the org buffer =indent-tabs-mode=, and redo every indentation with each conversion. This could possibly be costly when tangling a large buffer. The visual breakage would be much more common than those more serious issues, which had gone unnoticed so far. -- Sébastien Miquel
Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]
Sébastien Miquel writes: Should we use native buffer's value of =indent-tabs-mode= to set =use-tabs?= ? I think this trivial change should work. It doesn't seem quite that easy. If we want to add 4 columns to a tab indented line (and tab width is 8), we can either call =indent-to= to indent with a tab and 4 spaces, or add the spaces at the beginning. With the second option, we risk breaking vertical alignement in the org buffer. With the first option, on a subsequent edit, the current =org-do-remove-indentation= will break the tab character into 4 spaces, making the indentation 8 spaces instead of a tab. You need to have =org-do-remove-indentation= re-indent the whole line, with the correct value of =indent-tabs-mode=. -- Sébastien Miquel
Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]
Hi Ihor, Ihor Radchenko writes: ...But I guess what you propose amounts to ... You are right. On second thought, I don't think that's a good idea. I did not understand how tab characters worked: they do not have a fixed width, but align to the next tab column. This means that if we add a couple of spaces in front of a tab indented piece of code, we can break vertical alignment in the org buffer, which I think is pretty bad. Should we use native buffer's value of =indent-tabs-mode= to set =use-tabs?= ? I think this trivial change should work. -- Sébastien Miquel
Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]
Ihor Radchenko writes: ...But I guess what you propose amounts to ... You are right. I'll try to write a patch, this week-end. I was not aware of how we treated inline src blocks, but I don't think so. LaTeX fragments, in particular $$…$$ fragments, can have significant (for the user) newlines. May you provide an example? AFAIK, LaTeX usually treats newlines as whitespace, same with " ". When I say significant, I don't mean for compilation. When editing an array of equations for example, one might want to keep one equation per line in the buffer. Then, may latex-fragment-specific logic be moved to `org-edit-latex-fragment'? It already provides WRITE-BACK in the `org-src--edit-element' call. We may as well take care about clearing up indentation of the first line and other things there. Looks like it could, yes : call the WRITE-BACK after indentation. This doesn't seem to conflict for other org elements. -- Sébastien Miquel
Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]
Ihor Radchenko writes: What about the following approach: When converting from org-src buffer back to Org, 1. We do not touch the original indentation, except minimal common indentation of the whole src code, respecting the src mode value of `indent-tabs-mode'. 2. Minimal common indentation is treated according to `org-src-preserve-indentation'. 3. `org-src-preserve-indentation', when in effect, will add extra indentation of #+begin indentation + `org-src-preserve-indentation', now honouring `indent-tabs-mode' in Org buffer. When converting from Org to org-src buffer, 1. When `org-src-preserve-indentation' is in effect, remove the common `org-src-preserve-indentation' + #+begin indentation from the body. You've mixed up =org-src-preserve-indentation= and =org-edit-src-content-indentation= so I may misunderstand. But I guess what you propose amounts to 1. When =org-src-preserve-indentation= is =t=, do not touch indentation one way or the other (same as now). 2. Otherwise, do what we do now, but for the common indentation in the org buffer, use the org value of =indent-tabs-mode=, and for the rest of the indentation, use the native value of =indent-tabs-mode=. In this case, instead of trying to read this value, we might as well just blindly add the common indentation, to every non empty line. ... "- Item $abc\n efg$" Shouldn't newlines be removed completely before editing the body here? Just like what we do for inline src blocks. See `org-babel--normalize-body'. I was not aware of how we treated inline src blocks, but I don't think so. LaTeX fragments, in particular $$…$$ fragments, can have significant (for the user) newlines. May you provide an example? AFAIK, LaTeX usually treats newlines as whitespace, same with " ". When I say significant, I don't mean for compilation. When editing an array of equations for example, one might want to keep one equation per line in the buffer. -- Sébastien Miquel
Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]
Ihor Radchenko writes: I feel that we will be getting various edge cases like the original report and like the one I made up above if we keep trying to convert tabs/spaces. Just retaining the original code indentation will be much more robust, IMHO. Python code being broken with the default configuration is problematic, and fixing that seems worth the downsides (the indentation in an org file will now partially depend on the =indent-tabs-mode= settings of other modes, which cannot be set using buffer local variables). - =preserve-fl= is an isolated issue, and only concerns LaTeX fragments. I will attach a test with the issue it solves with multiline LaTeX fragments. I think LaTeX fragments are particular because in the org buffer they do not need to start at the beginning of a line. ... "- Item $abc\n efg$" Shouldn't newlines be removed completely before editing the body here? Just like what we do for inline src blocks. See `org-babel--normalize-body'. I was not aware of how we treated inline src blocks, but I don't think so. LaTeX fragments, in particular $$…$$ fragments, can have significant (for the user) newlines. Here are three patches attached. 1. Two tests : about editing LaTeX fragments, and preserving empty lines. LGTM. 2. Renaming of =preserve-blank-line=, for clarity. My concern is for `newline-and-indent'. Current line is _previous_ line in such scenario, not the newly inserted line. The way =newline-and-indent= works, I think, is that a newline is inserted, then =org-indent-line= is called, which preindents the line to the common org indentation, then calls =TAB= in a native edit buffer that does the rest of the indentation. The "current" line I refer to in the code is the new line (the "current" line is the one from which the native edit was called). -- Sébastien Miquel
Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]
Hi Ihor, wolf, Ihor Radchenko writes: Confirmed. This is caused by `org-src--contents-for-write-back' not adjusting blank line indentation in some cases. I don't think that's the issue. In fact, applying your diff didn't seem to solve the issue on my end. Generally, if you edit the given yaml in a =C-c C-'= buffer and go back to the org buffer with the default configuration, spaces will be converted to tabs, because =indent-tabs-mode= is =t= in the org buffer. I don't think there's much that we can do about it. We could try to read the value of =indent-tabs-mode= in the native buffer and preserve it in the org buffer, but then the org buffer would have mixed indentation all over, and that's exactly what the current code tries to avoid. To fix the original issue, you can set =indent-tabs-mode= to =nil= in your org files, or possibly set =org-preserve-indentation= to =t= (untested). I feel that the whole approach we use now with preserve-fl, use-tabs?, and preserve-blank-line is overcomplicated. Maybe someone can explain why we need all these special cases? The code does not reveal a whole lot. - =use-tabs?= seems pretty straightforward, its purpose is to respect the value of =indent-tabs-mode= in the org buffer. - =preserve-fl= is an isolated issue, and only concerns LaTeX fragments. I will attach a test with the issue it solves with multiline LaTeX fragments. I think LaTeX fragments are particular because in the org buffer they do not need to start at the beginning of a line. - The =preserve-blank-line= part (committed by me) is quite abstruse. Its name does not make any sense ! Originally, we did not try to reindent blank lines when writing back to the org buffer. I changed it so that when using =org-return=, the newline would get correctly indented, I think. Then I changed it again so that only the current blank line might get indented, see : https://list.orgmode.org/725763.1632663...@apollo2.minshall.org/T/ The variable =preserve-blank-line= decides whether we should indent the current blank line (if it is empty, we should maybe not). Here are three patches attached. 1. Two tests : about editing LaTeX fragments, and preserving empty lines. 2. Renaming of =preserve-blank-line=, for clarity. 3. Two more tests testing the behaviour of =org-return= and indentation, with the default configuration. When writing these, I found the behaviour was buggy in one case, and modified =org-indent-line= to fix it. Does that look alright to you ? Regards, -- Sébastien MiquelFrom 9613a54d20883e56301f987f5495b962f3763cad Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Sat, 17 Jun 2023 17:00:51 +0200 Subject: [PATCH] test-org-src.el: Add two tests * testing/lisp/test-org-src.el (test-org-src/preserve-empty-lines): Test that empty lines are not indented. (test-org-src/indented-latex-fragments): Test special edit of multiline indented LaTeX fragment. --- testing/lisp/test-org-src.el | 52 1 file changed, 52 insertions(+) diff --git a/testing/lisp/test-org-src.el b/testing/lisp/test-org-src.el index 2a45ba66e..42edb364a 100644 --- a/testing/lisp/test-org-src.el +++ b/testing/lisp/test-org-src.el @@ -144,6 +144,47 @@ This is a tab:\t. (org-edit-src-exit) (buffer-string)) +(ert-deftest test-org-src/preserve-empty-lines () + "Editing block preserves empty lines." + (should + (equal " +#+begin_src emacs-lisp + The following line is empty + + abc +#+end_src" + (org-test-with-temp-text + " +#+begin_src emacs-lisp + The following line is empty + + abc +#+end_src" + (let ((org-edit-src-content-indentation 2) + (org-src-preserve-indentation nil)) + (org-edit-special) + (org-edit-src-exit) + (buffer-string) + (should + (equal " +#+begin_src emacs-lisp + The following line is empty + + abc +#+end_src" + (org-test-with-temp-text + " +#+begin_src emacs-lisp + The following line is empty + + abc +#+end_src" + (let ((org-edit-src-content-indentation 2) + (org-src-preserve-indentation nil)) + (org-edit-special) + (org-edit-src-exit) + (buffer-string) ) + (ert-deftest test-org-src/coderef-format () "Test `org-src-coderef-format' specifications." ;; Regular tests in a src block, an example block and an edit @@ -376,6 +417,17 @@ This is a tab:\t. (org-edit-src-exit) (buffer-string)) +(ert-deftest test-org-src/indented-latex-fragments () + "Test editing multiline indented LaTeX fragment." + (should + (equal +"- Item $abc\n efg$" +(org-test-with-temp-text + "- Item $abc\n efg$" + (org-edit-special) + (org-edit-src-exit) + (buffer-string) + (ert-deftest test-org-src/footnote-references () "Test editing footnote references." ;;
Re: [POLL] Naming of "export features"
Ihor Radchenko writes:
Only the simplest cases of prepending/appending staff.
If we want to splice into the normal export template, users currently
must either write an output filter or rewrite the trnascoders
completely.
The proposed template system will provide more flexibility to modify the
default export transcoders.
Reading your original proposal, I see nothing that provides more
flexibility. I can guess at how it would allow one to prepend/append
stuff to the output of the default transcoder. Anything more flexible
than that would require breaking these default transcoders into parts,
which you did not originally mention.
Here's a couple interesting examples that currently cannot, I think.
+ a `multicol` heading property, that wraps the content of the
heading in a multicol environment.
Could you please illustrate with examples?
Exported content would be:
#+BEGIN_SRC latex
\section{ABC}
\begin{multicols}{3}
Section content
\end{multicols}
#+END_SRC
+ a `nocontent` property that do not export the content of the
heading
This can be done with :filter-parse-tree or :filter-headline
I guess. This isn't "couple of lines"-easy though.
+ Some way to play with the numbering of section, beyond the
`unumbered` property.
Could you elaborate what kind of "play" you are referring to?
I cannot think of anything that cannot be achieved through (somewhat
fragile) post-processing with `:filter-headline`.
Anyway, I was only trying to understand if your proposal could easily
do these things. What flexibility does it bring ?
It is indeed unfortunate that org doesn't provide an easy way to get
this behaviour, and achieving it would require the fragmentation
(templating ?) of at least some transcoders. I'm not sure that it
makes sense to do this for anything other than the headings
transcoders, and the main template.
Currently, transcoders are opaque functions that expose a limited number
of pre-defined settings. Turning them into templates will allow certain
non-standard alternations that we cannot think of in advance. Without
directly modifying the transcoder function code.
However, this seems orthogonal to your previous proposal. It is not
clear to me how it ties with your syntax.
Could you elaborate?
See higher. More flexibility requires breaking up some transcoders
into pieces. AFAIU it, the proposal you originally described does not
bring any more flexibility beyond what can be done through short
advices, or indeed the `:filter-` functions. I'm not sure this
dedicated syntax is preferable to advices.
--
Sébastien Miquel
Re: [PATCH] Introduce "export features"
Ihor Radchenko writes: The traditional user-facing approach for toggling staff in export is setting export options. Indeed. Then I suggest that such use be described in the manual. Having the user create a whole new option in order to toggle a `chikenize` package seems a bit unwieldy, however. What do you suggest instead of creating a new option? Timothy's patch supports having a feature depend on a variable. I was thinking here of a user variable (instead of an already defined org variable) that could be toggled per document. It is fairly orthogonal to the original purpose of the patch, but it does scratch an annoying itch of mine: there's very little support in org to minutely tweak the export on a per document basis, beyond the default options. One way to do this (easier than setting up a new option), is to define any variable, make the feature depend on it, and set it using the `#+bind` keyword. Combined with these export features, this could be used to easily tweak the LaTeX preamble, per document. If we find this use case to be legitimate and useful, I suggested earlier making it even easier with a `#+org_export_features` keyword. It would only take a list of feature names, and not require any variable tied to the feature. -- Sébastien Miquel
Re: [PATCH] Introduce "export features"
Ihor Radchenko writes: I think it would be useful to support an easy way to toggle a feature on and off. Either the manual should describe the best way to make a feature depend on a user variable (this requires using the #+BIND keyword, I guess), or I'd like org to support a new keyword, such as : #+org_export_features that would take a list of features, and enable them. Here, I am thinking of features such as the `chikenize` example in the manual. The traditional user-facing approach for toggling staff in export is setting export options. Indeed. Then I suggest that such use be described in the manual. Having the user create a whole new option in order to toggle a `chikenize` package seems a bit unwieldy, however. -- Sébastien Miquel
Re: [POLL] Naming of "export features"
Ihor Radchenko writes: Consider the feature request from the past about wrapping/prepending to exported headings: * Heading1 * Heading2 :PROPERTIES: :LATEX_TEMPLATE: (:snippet "\clearpage" :order -100) :END: # This Heading2 will start on a new page If we implement export transcoders as much as possible using templates, it will become very easy for users to adjust the export behavior beyond what is already possible. This can be achieved in a couple of lines with advices. Here's a couple interesting examples that currently cannot, I think. + a `multicol` heading property, that wraps the content of the heading in a multicol environment. + a `nocontent` property that do not export the content of the heading + Some way to play with the numbering of section, beyond the `unumbered` property. It is indeed unfortunate that org doesn't provide an easy way to get this behaviour, and achieving it would require the fragmentation (templating ?) of at least some transcoders. I'm not sure that it makes sense to do this for anything other than the headings transcoders, and the main template. However, this seems orthogonal to your previous proposal. It is not clear to me how it ties with your syntax. -- Sébastien Miquel
Re: [PATCH] Introduce "export features"
Hi, Timothy writes: Notably, I’ve now got a draft manual entry (see the last patch attached), which should go a long way to better explaining what this is without asking you to wade through all the code comments Thank you for sharing your work Timothy, I've been using your export features for a while. I think it would be useful to support an easy way to toggle a feature on and off. Either the manual should describe the best way to make a feature depend on a user variable (this requires using the #+BIND keyword, I guess), or I'd like org to support a new keyword, such as : #+org_export_features that would take a list of features, and enable them. Here, I am thinking of features such as the `chikenize` example in the manual. I have not tested it, but after a quick look at the patch, enabled features should be available to the export transcoder functions, through their =info= argument, aren't they ? This seems very useful. -- Sébastien Miquel
Re: [POLL] Naming of "export features"
Ihor Radchenko writes: However, it will be much harder to add something in the middle of the exported contents. I do like the original proposal. The latex preamble is something that a lot of users will want to modify, and is naturally made of a lot of concatenated snippets with little interdependence. But I don't see much point in extending the machinery for any org element. For most changes, you'll have to copy and modify the original transcoder's implementation anyway. At this point, you might as well write the feature logic in lisp (checking features through =info=), instead of your `transcoder-conditions`. -- Sébastien Miquel
Re: [POLL] Naming of "export features"
Hi,
Ihor Radchenko writes:
What I have in mind is an ability to parametrize the transcoders like
the following:
(org-export-define-backend 'html
'((paragraph . ((paragraph-is-a-link? figure-transcoder :name figure)
(:unless 'figure paragraph-transcoder
:transcoder-conditions
'((paragraph . ((paragraph-is-a-link? (lambda (paragraph contents
info)...))
Several ideas in the above:
1. Name features as "transcoder conditions"
2. The transcoder conditions are now linked to specific Org AST element.
They may not only be matched against the whole parse tree + whole raw
Org text, but also against the specific branch of AST + chunk of raw
Org text corresponding to the branch + the actual exported contents
of the AST children.
3. "feature implementations" are no longer needed. Instead, export
transcoders can contain the implementation lists inline. Each
implementation is selected not only depending on the presence of the
"feature"/transcoder condition, but also depending on multiple
features or arbitrary lisp expression results.
4. :when/:prevents apply to specific (possibly named) implementations.
This makes more sense than matching against feature.
For example, presence of svg images in latex export may or may not
mean that \usepackage{svg} is being used, depending on svg
implementation. We want to match against \usepackage{svg}
specifically rather than only against the presence of svg images.
What benefits does that bring over making enabled features available in
=info= for the usual transcoders and advising them ?
Your initial example of adding a comment to the end and beginning of the
document can be done by advising, say, =org-latex-template= and
concatenating some strings with its =content= argument.
--
Sébastien Miquel
Re: Need for dedicated kinds of paragraphs
Hi, Damien Cassou writes: I'm implementing an odt-based exporter for a French magazine named GNU/Linux Magazine. This magazine defines several kinds of boxes, which are small paragraphs of a certain type among "Default", "Attention", "Warning" and "PAO". When published, the magazine will change the background of these boxes depending on the type (e.g., using red color for warning boxes). I'm not sure what kind of markup to use nor how to transcode that markup. I tried with: #+BOX: attention This text will appear with a red background Does that make sense? Do you have a better suggestion? I think special blocks are a good fit for this purpose. -- Sébastien Miquel
Re: Support for tagging (special) blocks
Hi, Ihor Radchenko writes: Thanks for the clarification! I did not mean to reduce the font size in affiliated keywords. I was referring to replacing the display of affiliated keywords: #+name: A classic #+tag: easy will be displayed by Emacs as #+... A classic :easy: The underlying text will not be changed. The hidden parts will be revealed upon cursor entering the affiliated keywords. Perhaps something like #+... name: A classic tag: easy might be used for any kind of keyword. That'd be quite the trick. It would certainly improve the situation when an element has several keywords, but I'm not sure how common that is. I'll look into implementing such #+name and #+tag keywords, when I have the time. On an unrelated note, how is your work on revamping org's fontification going, if I may ask ? I had had a look at your repo, but since adapting my configuration would have required some effort I did not try it. -- Sébastien Miquel
Re: `org-fill-paragraph' (`M-q') in Org Mode source blocks
Ihor Radchenko writes: See the attached. I am not sure if we really need the variable. AFAIU, acting natively was the default in the past for M-q with no region selection. Then, I "fixed" some bug report in 05ee1e6ee06db and introduced the bug herein. You're right, I had not realised org-fill-element already acted natively. Your patch looks and tests good to me. -- Sébastien Miquel
Re: `org-fill-paragraph' (`M-q') in Org Mode source blocks
Hi, Ihor Radchenko writes: I am still getting the described behaviour. However, it does not happen in Org mode itself. `fill-paragraph' in emacs-lisp-mode does exactly the observed behaviour. Try 1. emacs -Q 2. insert ;; A comment (+ 2 2) 3. M-h M-q Is it emacs-lisp-mode bug? Or is it illegal to fill-region in source code buffers? I think the original report is about M-q, not M-h M-q. M-q behaves as expected in emacs-lisp-mode. Currently, org-fill-paragraph will not work properly when called inside src blocks. This can be easily fixed, but probably requires yet another org-fill-paragraph-act-natively variable. -- Sébastien Miquel
Re: Support for tagging (special) blocks
Ihor Radchenko writes: >> >> On a slightly related note, I find it quite unfortunate that one >> >> presently cannot make use of the #+begin_ line of special blocks to >> >> set some kind of optional title instead of using #+name or >> >> #+attr_latex. That's a lot of wasted real estate. >> > >> > Yes, but we do not want to overcomplicate Org syntax. Affiliated >> > keywords are universal across multiple element types. Adding a >> > specialized syntax for src blocks will make things complex technically >> > and create duplicate code. >> > >> > We can alter the fontification to compact the screen space though. Will >> > it suffice? >> > >> >> I don't see any possible compactification that doesn't hinder >> readability. From my perspective, it is important that the type of the >> special block, its title, and its tags are readable. > I feel that I either misunderstand you here or in the previous message. To clarify, here are the two alternatives I have in mind. #+tag: easy #+attr_latex: A classic #+begin_exercice Find a necessary and sufficient condition on $N$ and $P$ for $P = NP$ to hold. #+end_exercice #+begin_exercice A classic :easy: Find a necessary and sufficient condition on $N$ and $P$ for $P = NP$ to hold. #+end_exercice In my first message, I argue that wasting two lines of my screen hinders reading and navigating the whole org file. I'm not sure what fontification trick you had in mind to compact the space, but if you were thinking of making the meta lines smaller, by say 50%, I argue in my second message that this hinders the readability of this single exercice. The first three lines each contain information that is important to me when I browse the file (as opposed to information that's only relevant for org export). The only line that contains no content information is the #+end_exercice line, which is only here for the org parser. -- Sébastien Miquel
Re: Support for tagging (special) blocks
Ihor Radchenko writes: > Sébastien Miquel writes: > >> Ihor Radchenko writes: >> > They do not. Tags are only considered inside headlines. Trying to allow >> > tags outside headlines will require major changes across the whole Org >> > codebase and will still make things incompatible with third party >> > packages, like org-ql. Not to mention the whole new concept for block >> > syntax. >> >> Tags on block do not need to have the same support as headlines tags. >> I'm not suggesting they should interact with the agenda or whatnot. >> Support could be behind a user option, and consist only of say easy >> tag edition, and `#+exclude_tags:` support. With that scope, the >> implementation should be fairly simple. As for third party packages, >> it is up to them whether to extend their features to tagged blocks ; >> in some case it might not make sense. > > We already have ":exports none" header argument. For src block yes, but not for special blocks. To explain where I'm coming from : I write mathematical content categorized using special blocks, such as theorems, exercices, proofs, personnal notes, etc. Then from a single org file, I export several pdf files, filtering the content according to the types and tags of special blocks : for example, to exclude some proofs, or exercices that are too hard. > >> > If one wants to add "tags" or other keywords associated with blocks or >> > other Org elements, the right tool to use is affiliated keywords. But >> > note that Org search infrastructure is tailored towards searching >> > headlines. >> >> Two inconvenients with using affiliated keywords. >>1. There would be no uniform treatment with headline tags. In my use, >> I have the same tags on headline and blocks, and I filter the >> export according to them with #+exclude_tags. > > Affiliated keywords are indeed not uniform with headlines. But they are > uniform with everything else. Paragraphs can have affiliated keywords. > Or other blocks. Or lists. Or tables... That's indeed a good point. In fact, I had been wondering recently how I could tag a single list item, but I guess affiliated keywords still can't do that. > >>2. They waste too much space. Say I have some 20 short exercices >> (represented by special blocks). Since I dot not display the >> #+end_ line, each of them takes 2 or 3 lines in my screen. If I >> want to tag those using affiliated keywords that makes for a 50% >> or 33% size increase, with very poor readability. > >> On a slightly related note, I find it quite unfortunate that one >> presently cannot make use of the #+begin_ line of special blocks to >> set some kind of optional title instead of using #+name or >> #+attr_latex. That's a lot of wasted real estate. > > Yes, but we do not want to overcomplicate Org syntax. Affiliated > keywords are universal across multiple element types. Adding a > specialized syntax for src blocks will make things complex technically > and create duplicate code. > > We can alter the fontification to compact the screen space though. Will > it suffice? > I don't see any possible compactification that doesn't hinder readability. From my perspective, it is important that the type of the special block, its title, and its tags are readable. One thing that org can do in that regard is hide the #+end_ line. For special blocks, a requirement is that the org-block face should apply to them too, to see where the block ends. -- Sébastien Miquel
Re: Support for tagging (special) blocks
Hi, Ihor Radchenko writes: > They do not. Tags are only considered inside headlines. Trying to allow > tags outside headlines will require major changes across the whole Org > codebase and will still make things incompatible with third party > packages, like org-ql. Not to mention the whole new concept for block > syntax. Tags on block do not need to have the same support as headlines tags. I'm not suggesting they should interact with the agenda or whatnot. Support could be behind a user option, and consist only of say easy tag edition, and `#+exclude_tags:` support. With that scope, the implementation should be fairly simple. As for third party packages, it is up to them whether to extend their features to tagged blocks ; in some case it might not make sense. > If one wants to add "tags" or other keywords associated with blocks or > other Org elements, the right tool to use is affiliated keywords. But > note that Org search infrastructure is tailored towards searching > headlines. Two inconvenients with using affiliated keywords. 1. There would be no uniform treatment with headline tags. In my use, I have the same tags on headline and blocks, and I filter the export according to them with #+exclude_tags. 2. They waste too much space. Say I have some 20 short exercices (represented by special blocks). Since I dot not display the #+end_ line, each of them takes 2 or 3 lines in my screen. If I want to tag those using affiliated keywords that makes for a 50% or 33% size increase, with very poor readability. On a slightly related note, I find it quite unfortunate that one presently cannot make use of the #+begin_ line of special blocks to set some kind of optional title instead of using #+name or #+attr_latex. That's a lot of wasted real estate. -- Sébastien Miquel
Support for tagging (special) blocks
Hi, I've been using tags on special blocks, src blocks and other, for two purposes: 1. to control which blocks get exported, using the `#+exclude_tags` property. 2. to fine tune the export, according to tags, of special blocks such as #+BEGIN_exercice:hard: … #+END_exercice Does anyone think this is useful and might warrant adding support for ? -- Sébastien Miquel
Re: [PATCH] Make :var foo=name-of-src-block assign the source block code instead of currently assigned result of evaluation (was: [PATCH] Add :noweb-prefix and :noweb-trans babel header arguments)
Hi Ihor,
I've implemented this proposal in the patch attached.
Does it look good to you ?
--
Sébastien MiquelFrom b1b783dc80821b07937ac4211ec28df8726fff1c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?=
Date: Sat, 13 Aug 2022 20:49:27 +0200
Subject: [PATCH] New babel syntax to pass src block contents as argument
* lisp/ob-ref.el (org-babel-ref-resolve): Add support for
`named-block[]' syntax, resolving to the contents of a named-block.
* lisp/ob-core.el (org-babel-read-element): Read a code block into its
contents, like other blocks.
* testing/listp/test-ob.el (test-ob/block-content-resolution): Test
block content resolution.
* doc/org-manual.org: Document syntax.
* etc/ORG-NEWS: Document syntax.
---
doc/org-manual.org | 7 ---
etc/ORG-NEWS| 5 +
lisp/ob-core.el | 2 +-
lisp/ob-ref.el | 10 ++
testing/lisp/test-ob.el | 15 +++
5 files changed, 31 insertions(+), 8 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 57a57a6fe..794682b49 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -17505,9 +17505,10 @@ a colon, for example: =:var table=other-file.org:example-table=.
: 4
#+end_example
-- literal example ::
+- literal example, or code block contents ::
- A literal example block named with a =NAME= keyword.
+ A code block or literal example block named with a =NAME= keyword,
+ followed by brackets (optional for example blocks).
#+begin_example
,#+NAME: literal-example
@@ -17517,7 +17518,7 @@ a colon, for example: =:var table=other-file.org:example-table=.
,#+END_EXAMPLE
,#+NAME: read-literal-example
- ,#+BEGIN_SRC emacs-lisp :var x=literal-example
+ ,#+BEGIN_SRC emacs-lisp :var x=literal-example[]
(concatenate #'string x " for you.")
,#+END_SRC
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 7dae03dc6..d6d99a64b 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -288,6 +288,11 @@ The =org-md-toplevel-hlevel= customization variable sets the heading
level used for top level headings, much like how
=org-html-toplevel-hlevel= sets the heading level used for top level
headings in HTML export.
+*** Babel: new syntax to pass the contents of a src block as argument
+
+Use the header argument =:var x=code-block[]= or
+: #+CALL: fn(x=code-block[])
+to pass the contents of a named code block as a string argument.
** New options
*** A new custom setting =org-hide-drawer-startup= to control initial folding state of drawers
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 68dd5557c..c52ef9ed6 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -2156,7 +2156,7 @@ Return nil if ELEMENT cannot be read."
(or (org-babel--string-to-number v) v)))
(`table (org-babel-read-table))
(`plain-list (org-babel-read-list))
- (`example-block
+ ((or `example-block `src-block)
(let ((v (org-element-property :value element)))
(if (or org-src-preserve-indentation
(org-element-property :preserve-indent element))
diff --git a/lisp/ob-ref.el b/lisp/ob-ref.el
index 87a7ccf63..ee2745e09 100644
--- a/lisp/ob-ref.el
+++ b/lisp/ob-ref.el
@@ -124,12 +124,14 @@ Emacs Lisp representation of the value of the variable."
(save-excursion
(let ((case-fold-search t)
args new-refere new-header-args new-referent split-file split-ref
- index)
+ index contents)
;; if ref is indexed grab the indices -- beware nested indices
- (when (and (string-match "\\[\\([^\\[]+\\)\\]$" ref)
+ (when (and (string-match "\\[\\([^\\[]*\\)\\]$" ref)
(let ((str (substring ref 0 (match-beginning 0
(= (cl-count ?\( str) (cl-count ?\) str
- (setq index (match-string 1 ref))
+(if (> (length (match-string 1 ref)) 0)
+ (setq index (match-string 1 ref))
+ (setq contents t))
(setq ref (substring ref 0 (match-beginning 0
;; assign any arguments to pass to source block
(when (string-match
@@ -171,7 +173,7 @@ Emacs Lisp representation of the value of the variable."
(throw :found
(org-babel-execute-src-block
nil (org-babel-lob-get-info e) params)))
- (`src-block
+ ((and `src-block (guard (not contents)))
(throw :found
(org-babel-execute-src-block
nil nil
diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el
index a62bd56bf..c944ccd39 100644
--- a/testing/lisp/test-ob.el
+++ b/testing/lisp/test-ob.el
@@ -178,6 +178,21 @@ should still return the link."
(point-at-bol)
(point-at-eol))
+(ert-deftest test-ob/block-content-resolution ()
+ "Test block content resolution."
+ (org-test-with-temp-text-in-file "
+
+#+name: four
+#+begin_src emacs-lisp
+ (list 1 2 3 4)
+#+end_src
+
+#+begin_src emacs-lisp :var four=four[]
+ (length (eval (car (read-from-string four
+#+end_src"
+ (org-babel-next-src-block 2)
+ (should
Re: [PATCH] org-babel: Do not echo output of resolved noweb references
Hi, Ihor Radchenko writes: > Let me know if you see any potential issues with the proposed change. Thanks for looking into this. I think the change looks right, though I am no great user of org-babel and its header arguments. Regards, -- Sébastien Miquel
Re: [PATCH] lisp/org.el: Fix `org-fill-paragraph' in lists when `mark-active'
Hi, Renato Ferreira writes: > Go to start of list, `org-mark-element`, then `org-fill-paragraph`. The first item does not get filled. This should be fixed on main. If not, please say so. I'm removing this from updates.orgmode.org: Canceled. -- Sébastien Miquel
Re: bug#52771: 29.0.50; org-fill-paragraph does not work for several plain lists
Kyle Meyer writes: > Rudolf Adamkovič writes: > >> Reproduction steps: >> >> 1. start "emacs -Q" >> 2. type "C-x C-f" and "test.org" and RET >> 3. type the following: >> >> - one >> two >> >> - three >> four >> >> 4. mark all with "C-x h" >> 5. type "M-q" to fill >> >> Actual: >> >> - one >> two >> >> - three four >> >> Expected: >> >> - one two >> >> - three four This is fixed on main. Marking it as resolved on updates.orgmode.org: Fixed. -- Sébastien Miquel
Re: [FR] Make :var foo=name-of-src-block assign the source block code instead of currently assigned result of evaluation (was: [PATCH] Add :noweb-prefix and :noweb-trans babel header arguments)
Hi, Ihor Radchenko writes: > Hmm. You are right. I missed "optionally". > > Still, I find this idea as the best solution for people who want to > process the source block text during noweb expansion. > > Alternative ideas are welcome though. I'd prefer to avoid breaking > change if we can find an equally simple syntax alternative to assign > source block code to a variable. The uses are maybe too niche to warrant the breaking change. A syntax extension like : var=block-id[] seems possible, even though brackets are already overloaded. One alternative is to only allow the syntax inside noweb brackets instead of generic variable arguments. I assume there'd be much less breakage. It would also makes sense to allow noweb references instead of block ids. We'd add support for : <> and <> would also insert the contents as a by-product. Do you have any example of use in mind, beyond my original one ? Regards, -- Sébastien Miquel
Re: Bug: org-edit-special indents inline latex [9.5 (nil @ /home/david/.emacs.d/.local/straight/build-27.2/org-mode/)]
Marking this as resolved on updates.orgmode.org, 2nd try. |Fixed.| -- Sébastien Miquel
Re: Bug: org-edit-special indents inline latex [9.5 (nil @ /home/david/.emacs.d/.local/straight/build-27.2/org-mode/)]
Marking this as resolved on updates.orgmode.org. |Fixed.| -- Sébastien Miquel
Re: [PATCH] org.el (org-latex-preview): With an active region, act on it
Marking this as resolved on updates.orgmode.org. Applied. -- Sébastien Miquel
Re: [PATCH] org.el: Fix the filling of regions containing lists
Applied, as 4e4250061. Took a little while :P -- Sébastien Miquel
Re: [PATCH] org.el (org-format-latex-header): put DEFAULT-PACKAGES before PACKAGES
Ihor Radchenko writes:
Thanks for the clarification! Now, your patch makes much more sense. Can
you update the commit message explaining the above shortly and linking
to this thread?
See attached.
Thanks,
--
Sébastien Miquel
From 72742cab341f66525e0acb0b92de65fb6d24c27f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?=
Date: Mon, 13 Jun 2022 11:04:34 +0200
Subject: [PATCH] org.el (org-format-latex-header): put DEFAULT-PACKAGES before
PACKAGES
* lisp/org.el (org-format-latex-header): put DEFAULT-PACKAGES before
PACKAGES, as per org-latex-packages-alist's documentation.
`org-format-latex-header' is mostly used to generate in-buffer images
from LaTeX fragments. For LaTeX document export, the header is
generated by `org-splice-latex-header' ond `org-latex-classes' instead
and the default and documented behaviour is to insert DEFAULT-PACKAGES
before PACKAGES.
See also
https://list.orgmode.org/877d5gg5rt.fsf@localhost/T/#m2ad2f3b1509e1af72016e8e6fad3557ff3083046
---
lisp/org.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/org.el b/lisp/org.el
index 95dff27ad..0acfa4846 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3248,8 +3248,8 @@ images at the same place."
(defcustom org-format-latex-header "\\documentclass{article}
\\usepackage[usenames]{color}
-\[PACKAGES]
\[DEFAULT-PACKAGES]
+\[PACKAGES]
\\pagestyle{empty} % do not remove
% The settings below are copied from fullpage.sty
\\setlength{\\textwidth}{\\paperwidth}
--
2.36.1
Re: [PATCH] org.el (org-format-latex-header): put DEFAULT-PACKAGES before PACKAGES
Hi, Ihor Radchenko writes: We actually have 2 options here: 1. Change the docstring 2. Change the template Can moving [PACKAGES] up break the existing configs? It might. I am inclined to change the docstring instead. Thanks for having a look at this. It makes more sense for a package in PACKAGES to depend on a DEFAULT-PACKAGE than vice versa. =org-latex-packages-alist= and =org-latex-classes=' are two important docstrings. People are likely to have crafted their configuration by reading these documentation. I've also just checked that by default, for document export, DEFAULT-PACKAGES are inserted before PACKAGES --- the default templates from =org-latex-classes= do not include =DEFAULT-PACKAGES= nor =PACKAGES=, and in this case, =org-splice-latex-header= adds both default packages and packages at the end, with default packages coming first. =org-format-latex-header= is only used to generate images for preview, and in some cases by ob-latex to compile a document from a LaTeX src block. Regards, -- Sébastien Miquel
[PATCH] org.el (org-format-latex-header): put DEFAULT-PACKAGES before PACKAGES
Hi,
The attached patch puts DEFAULT-PACKAGES before PACKAGES in
org-format-latex-header, as per org-latex-packages-alist's and
org-latex-classes' documentations.
Regards,
--
Sébastien Miquel
From 983e35f19371e3ea85ed28bd46f36ea5a52a3950 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?=
Date: Mon, 13 Jun 2022 11:04:34 +0200
Subject: [PATCH] org.el (org-format-latex-header): put DEFAULT-PACKAGES before
PACKAGES
* lisp/org.el (org-format-latex-header): put DEFAULT-PACKAGES before
PACKAGES, as per org-latex-packages-alist's documentation.
---
lisp/org.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/org.el b/lisp/org.el
index 95dff27ad..0acfa4846 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3248,8 +3248,8 @@ images at the same place."
(defcustom org-format-latex-header "\\documentclass{article}
\\usepackage[usenames]{color}
-\[PACKAGES]
\[DEFAULT-PACKAGES]
+\[PACKAGES]
\\pagestyle{empty} % do not remove
% The settings below are copied from fullpage.sty
\\setlength{\\textwidth}{\\paperwidth}
--
2.36.1
Re: [PATCH] org.el (org-latex-preview): With an active region, act on it
Hi, Daniel Fleischer writes: Hi Miquel, thanks for the patch! It's useful and works nicely - both in creating and removing the previews. Let's give it a couple more days for feedback and then feel free to merge the patch. Thanks for your comment and testing this. Note that I do not have merge access to the repository. Regards, -- Sébastien Miquel
[PATCH] org.el (org-latex-preview): With an active region, act on it
Hi, The attached patch modifies org-latex-preview to display all images of latex fragments in a region, when one is active. Using prefix arguments it is already possible to display all images in the buffer, or in the current section, but I find it often too slow and unnecessary. Regards, -- Sébastien Miquel From 2c9b72731247620dea2aed96a0a83385472e29cc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Wed, 8 Jun 2022 13:11:12 +0200 Subject: [PATCH] org.el (org-latex-preview): With an active region, act on it * lisp/org.el (org-latex-preview): With an active region, display images for all fragments in the region. With universal prefix argument, remove all images in the region. --- lisp/org.el | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 95dff27ad..07f481647 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -15307,7 +15307,8 @@ BEG and END are buffer positions." If the cursor is on a LaTeX fragment, create the image and overlay it over the source code, if there is none. Remove it otherwise. If there is no fragment at point, display images for -all fragments in the current section. +all fragments in the current section. With an active region, +display images for all fragments in the region. With a `\\[universal-argument]' prefix argument ARG, clear images \ for all fragments @@ -15335,10 +15336,18 @@ fragments in the buffer." ;; Clear current section. ((equal arg '(4)) (org-clear-latex-preview - (if (org-before-first-heading-p) (point-min) - (save-excursion - (org-with-limited-levels (org-back-to-heading t) (point - (org-with-limited-levels (org-entry-end-position + (if (use-region-p) + (region-beginning) + (if (org-before-first-heading-p) (point-min) + (save-excursion + (org-with-limited-levels (org-back-to-heading t) (point) + (if (use-region-p) + (region-end) + (org-with-limited-levels (org-entry-end-position) + ((use-region-p) +(message "Creating LaTeX previews in region...") +(org--latex-preview-region (region-beginning) (region-end)) +(message "Creating LaTeX previews in region... done.")) ;; Toggle preview on LaTeX code at point. ((let ((datum (org-element-context))) (and (memq (org-element-type datum) '(latex-environment latex-fragment)) -- 2.36.1
Re: [PATCH] lisp/org.el: Fix `org-fill-paragraph' in lists when `mark-active'
Hi, Renato Ferreira writes: I stumbled upon a bug introduced by it: filling lists with active region. # MRE: Go to start of list, `org-mark-element`, then `org-fill-paragraph`. The first item does not get filled. ```org * This is a test - Aliquam erat volutpat. Nunc eleifend leo vitae magna. In id erat non orci commodo lobortis. Proin neque massa, cursus ut, gravida ut, lobortis eget, lacus. Sed diam. Praesent fermentum tempor. - Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit tempor tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt et, mattis eget, convallis nec, purus. Cum sociis natoque. - Aliquam erat volutpat. Nunc eleifend leo vitae magna. In id erat non orci commodo lobortis. Proin neque massa, cursus ut, gravida ut, lobortis eget, lacus. Sed diam. Praesent fermentum tempor tellus. ``` See also https://list.orgmode.org/041ca43d-2efb-db1e-76ab-7c15af088...@posteo.eu/ where I submitted a different patch that fixes this issue (I think) and a couple of others. Regards, -- Sébastien Miquel
Re: [PATCH] Add :noweb-prefix and :noweb-trans babel header arguments
Hi, Ihor Radchenko writes: Can you provide more concrete examples? Some drawbacks: + doesn't work for all languages (does work for LaTeX) Which languages do not work? Most languages do not work. Using your proposed solution, what I'm trying to do is #+name:javascript-header #+begin_src javascript :tangle no some javascript, with \ and " to be escaped #+end_src #+name: string-escape #+begin_src emacs-lisp :var str="" :tangle no (prin1-to-string (string-trim-right str)) #+end_src #+begin_src emacs-lisp :noweb yes :tangle yes (setq javascript-header <>) #+end_src If you replace javascript with latex, it happens to work, because when org executes a latex block, it prints its content. The goal is to tangle to some lisp code whose purpose is to generate LaTeX/javascript code. Quite niche admittedly, though as you showed, it could also be used to string-escape documentation. + the tangle gets very noisy: not only are the result of execution printed in the echo buffer, but emacs visits the tangling buffer and moves the point to each block. Perhaps this is a bug that can be fixed. Did you try to play with :results header argument to disable messages? What exactly went unexpected? I did. I might have missed something, but no combination of :results argument to both the latex block and the string-escape block silences the tangle (except for :results none, which doesn't tangle the content of the block). During tangle, the contents of the latex block are displayed (shortly) in the echo buffer (check *Messages*), and the point very briefly moves to the latex block. This isn't very noticeable with a single block. + src block execution also resets the noweb cache, slowing down tangle, though I have not tried to measure the effect. I am not sure what you are referring to here. Can you elaborate? Lines 2892-2893 of (my) ob-core.el, in org-babel-expand-noweb-references: ;; Evaluation can potentially modify the buffer ;; and invalidate the cache: reset it. Regards, -- Sébastien Miquel
Re: [PATCH] Add :noweb-prefix and :noweb-trans babel header arguments
Hi, Ihor Radchenko writes: Thinking about the whole idea of :noweb-trans more, I see little benefit compared to something like: #+name: documentation This is a sample function documentation. Because there are "quotes", it must be escaped and cannot be directly used as noweb-reference. #+name: doc-escape #+begin_src emacs-lisp :var str="" :tangle no (prin1-to-string (string-trim-right str)) #+end_src #+begin_src emacs-lisp :tangle yes (defun test () <> t) #+end_src I had converted my uses (tangling code, not text/documentation) to this but I ended up reverting. Some drawbacks: + doesn't work for all languages (does work for LaTeX) + the tangle gets very noisy: not only are the result of execution printed in the echo buffer, but emacs visits the tangling buffer and moves the point to each block. Perhaps this is a bug that can be fixed. + src block execution also resets the noweb cache, slowing down tangle, though I have not tried to measure the effect. As stated in the OP, I find it unfortunate that org does not provide any way to tangle the content of a src block to a string representing this code. If anyone shows any interest, I've provided two possible implementations in this thread, that I can rebase. Regards, -- Sébastien Miquel
Re: [PATCH] New LaTeX code export option: engraved
Hi, Timothy writes: 2. `minted` supports a `mathescape` option to render math content inside code. `fvextra` supports the same option, but maths characters are escaped by engrave-faces-latex-face-mapper. I’l also take a look at this:) Implemented in engrave-faces-latex, but not worked into ox-html yet. If you could check it out on the engrave-faces-latex side and check it’s behaving sanely, that would be helpful. I've tried it, and mathescape works, thanks ! -- Sébastien Miquel
Re: [PATCH] New LaTeX code export option: engraved
Hi Timothy, I'm quite exited and impressed to see this alternative to minted, thank you. I haven't been able to test your patches to org, but I have tried engrave-faces.el. Here's a couple issues I've run into. 1. engrave-faces-generate-preset generates emacs colors such as `:foreground "grey70"` which are not supported by engrave-faces-latex-gen-preamble-line and co. 2. `minted` supports a `mathescape` option to render math content inside code. `fvextra` supports the same option, but maths characters are escaped by engrave-faces-latex-face-mapper. Regards, -- Sébastien Miquel
Re: [PATCH] Add :noweb-prefix and :noweb-trans babel header arguments
Ihor Radchenko writes:
#+name: documentation
This is a sample function documentation.
Because there are "quotes", it must be escaped and cannot be directly
used as noweb-reference.
#+name: doc-escape
#+begin_src emacs-lisp :var str="" :tangle no
(prin1-to-string (string-trim-right str))
#+end_src
#+begin_src emacs-lisp :tangle yes
(defun test ()
<>
t)
#+end_src
Nice ! Quite obscure and brittle (doesn't work if documentation is a
text src block) but I can use it nonetheless.
Other than :noweb-trans, the patch looks good for me.
Here's a patch with only the :noweb-prefix part. If applied, we can mark
this thread resolved.
Thanks,
--
Sébastien Miquel
From 3fc3c3557b27026e2cfdb2a1973921c1baf3758a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?=
Date: Mon, 6 Sep 2021 18:45:42 +0200
Subject: [PATCH] ob-core.el: Add `:noweb-prefix` babel header argument
* lisp/ob-core.el (org-babel-expand-noweb-references): Add support for
`noweb-prefix' header argument, to not repeat the prefix characters
when expanding a noweb reference.
(org-babel-common-header-args-w-values):
(org-babel-safe-header-args): Add `noweb-prefix' value.
* doc/org-manual.org: Document `noweb-prefix' babel header argument.
* etc/ORG-NEWS: Document `:noweb-prefix'.
---
doc/org-manual.org | 17 +
etc/ORG-NEWS | 6 +-
lisp/ob-core.el| 17 -
3 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 6768ca98d..c9c1c1298 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -18760,6 +18760,23 @@ else:
print('do things when false')
#+end_example
+This prefix behavior can be turned off in a block by setting the
+=noweb-prefix= header argument to =no=, as in:
+
+#+begin_example
+,#+BEGIN_SRC elisp :noweb-prefix no
+ (setq example-data "<>")
+,#+END_SRC
+#+end_example
+
+#+texinfo: @noindent
+which expands to:
+
+#+begin_example
+(setq example-data "this is the
+multi-line body of example")
+#+end_example
+
When in doubt about the outcome of a source code block expansion, you
can preview the results with the following command:
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 2b539d305..1e8558c7b 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -150,7 +150,7 @@ The entry points are ~org-persist-register~, ~org-persist-unregister~,
~org-persist-read~, and ~org-persist-read-all~. Storing circular
structures is supported. Storing references between different
variables is also supported (see =:inherit= key in
-~org-persist-register~).
+~org-persist-register~).
The library permits storing buffer-local variables. Such variables
are linked to the buffer text, file =inode=, and file path.
@@ -175,6 +175,10 @@ the =compact-itemx= export option, or globally using the
Items in a description list that begin with =Function:=, =Variable:=
or certain related prefixes are converted using Texinfo definition
commands.
+*** New =:noweb-prefix= babel header argument
+
+=:noweb-prefix= can be set to =no= to prevent the prefix characters
+from being repeated when expanding a multiline noweb reference.
** New functions and changes in function arguments
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 65907..09d6adfe0 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -413,6 +413,7 @@ then run `org-babel-switch-to-session'."
(noweb . ((yes no tangle no-export strip-export)))
(noweb-ref . :any)
(noweb-sep . :any)
+(noweb-prefix . ((no yes)))
(output-dir . :any)
(padline . ((yes no)))
(post . :any)
@@ -438,8 +439,8 @@ specific header arguments as well.")
(defconst org-babel-safe-header-args
'(:cache :colnames :comments :exports :epilogue :hlines :noeval
- :noweb :noweb-ref :noweb-sep :padline :prologue :rownames
- :sep :session :tangle :wrap
+ :noweb :noweb-ref :noweb-sep :noweb-prefix :padline
+ :prologue :rownames :sep :session :tangle :wrap
(:eval . ("never" "query"))
(:results . (lambda (str) (not (string-match "file" str)
"A list of safe header arguments for babel source blocks.
@@ -2827,6 +2828,10 @@ block but are passed literally to the \"example-block\"."
(lang (nth 0 info))
(body (nth 1 info))
(comment (string= "noweb" (cdr (assq :comments (nth 2 info)
+ (noweb-prefix (let ((v (assq :noweb-prefix (nth 2 info
+ (or (not v)
+ (and (org-not-nil (cdr v))
+ (not (equal (cdr v) "no"))
(noweb-re (format "\\(.*?\\)\\(%s\\)"
(with-current-buffer parent-buffer
(org-babel-noweb-wrap
@@ -2923,9 +2928,11 @@ block but are passed literally to the \"example-block\"."
(push info (gethash ref cache))
(funcall
Re: [PATCH] Add :noweb-prefix and :noweb-trans babel header arguments
Hi,
Ihor Radchenko writes:
prin1-to-string is too specific and only solves a single use-case.
prin1-to-string is actually universal in a way, since any other
manipulation can then be achieved with
: (setq var (do-something <>))
at least as long as you're tangling to a programming language, that
can read lisp strings.
Consider the following example:
#+BEGIN_SRC emacs-lisp :noweb yes :tangle yes :noweb-prefix no :noweb-trans
prin1-to-string
<>
(setq latex-header <>)
#+END_SRC
There are two noweb references here. Setting source block-wide
:noweb-trans is not helpful because the first reference will be
incorrectly filtered through prin1-to-string.
Indeed. Originally I had thought of adding a new syntax <<"nw">> to
insert a string representation. I've attached a new patch, that does
this instead of introducing :noweb-trans. Now that I think of the
universality of prin1-to-string, I actually like it slightly better
than :noweb-trans. It would break existing "nw"-like noweb references.
Of course, one can work around this easily enough by using two blocks.
I'd rather introduce a new syntax to transform the noweb reference
inline. Something like
#+BEGIN_SRC emacs-lisp :noweb yes :tangle yes :noweb-prefix no
<>
(setq latex-header <<(prin1-to-string nw)>>)
#+END_SRC
You'd need to only allow a single function call with only one
argument, or use something like <<(prin1-to-string <>)>>. The
change would be much more complex than what I propose, for maybe
little benefit.
[...]
This sounds a bit confusing. I would also add an example where it is
useful to set :noweb-prefix to no.
I've added such an example in the revised patch attached.
Thanks for the feedback.
Regards,
--
Sébastien Miquel
From 99d043b9d837a2658e60fb4b4913454d9566519b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?=
Date: Mon, 6 Sep 2021 18:45:42 +0200
Subject: [PATCH] ob-core.el: Add `:noweb-prefix`, `:noweb-trans` babel header
arguments
* lisp/ob-core.el (org-babel-expand-noweb-references): Add support for
`noweb-prefix' header argument, to not repeat the prefix characters
when expanding a noweb reference. Add support for `noweb-trans' header
argument, to apply a function to the noweb content upon
expansion.
(org-babel-common-header-args-w-values):
(org-babel-safe-header-args): Add `noweb-prefix' and `noweb-trans' values.
* doc/org-manual.org: Document `noweb-prefix' and `noweb-trans' babel header
arguments.
* etc/ORG-NEWS: Document `:noweb-prefix' and `:noweb-trans'.
---
doc/org-manual.org | 42 ++
etc/ORG-NEWS | 10 +-
lisp/ob-core.el| 26 --
3 files changed, 71 insertions(+), 7 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 6768ca98d..5ef8e2f8b 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -18760,6 +18760,48 @@ else:
print('do things when false')
#+end_example
+This prefix behavior can be turned off in a block by setting the
+=noweb-prefix= header argument to =no=, as in:
+
+#+begin_example
+,#+BEGIN_SRC elisp :noweb-prefix no
+ (setq example-data "<>")
+,#+END_SRC
+#+end_example
+
+#+texinfo: @noindent
+which expands to:
+
+#+begin_example
+(setq example-data "this is the
+multi-line body of example")
+#+end_example
+
+The header argument =noweb-trans= can be set to =prin1-to-string= to
+insert a lisp string representing the content of the referenced src
+block. With:
+
+#+begin_example
+,#+NAME: latex-header
+,#+BEGIN_SRC latex
+ \usepackage{amsmath}
+,#+END_SRC
+#+end_example
+
+#+texinfo: @noindent
+this code block:
+
+#+begin_example
+,#+BEGIN_SRC elisp :noweb yes :noweb-trans prin1-to-string
+ (setq header <>)
+,#+END_SRC
+#+end_example
+
+#+texinfo: @noindent
+expands to:
+
+: (setq header "\\usepackage{amsmath}")
+
When in doubt about the outcome of a source code block expansion, you
can preview the results with the following command:
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 2b539d305..70f7606db 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -150,7 +150,7 @@ The entry points are ~org-persist-register~, ~org-persist-unregister~,
~org-persist-read~, and ~org-persist-read-all~. Storing circular
structures is supported. Storing references between different
variables is also supported (see =:inherit= key in
-~org-persist-register~).
+~org-persist-register~).
The library permits storing buffer-local variables. Such variables
are linked to the buffer text, file =inode=, and file path.
@@ -175,6 +175,14 @@ the =compact-itemx= export option, or globally using the
Items in a description list that begin with =Function:=, =Variable:=
or certain related prefixes are converted using Texinfo definition
commands.
+*** New =:noweb-prefix= and =:noweb-trans= babel header arguments
+
+=:noweb-prefix= can be set to =no= to preve
Re: Bug: asynchronous export (org-mode 9.4.4, emacs 27.2)
M. Pger writes: Thx for your answer. I've just upgraded org-mode (elpa way) and I am now using version 9.5.2. Version 9.5.2 should indeed contain the fix I had in mind : https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c91271297dbbfc831874d7880343603881bdac9c Unfortunately this does not work, I still end up with: Invalid read syntax: "#" Can you check that the right version of org-mode is picked-up, with `describe-function` `org-latex-export-to-pdf`, find the function definition by following the `ox-latex.el` link, and check that the source contains the linked patch ? I would like to try the alternative, i.e. disabling native-comp (for the export function I guess). Would you mind telling me how to do that? `describe-function` should also tell you whether the function is native compiled. If it is, you can temporarily 'uncompile' by evaluating its source code. By disabling native compilation I meant as a compile flag, if you've built emacs from source. I cannot find an easy way to prevent native compilation of a single package/function. -- Sébastien Miquel
Re: Bug: asynchronous export (org-mode 9.4.4, emacs 27.2)
Hi, M. Pger writes: When trying to asynchronously export, I get the following error: "Process `org-export-process'exited abnormally". The *Org Export Process* buffer gives the following: Invalid read syntax: "#". A similar issue was fixed in master. Try the latest version of org-mode. Alternatively, disabling native-comp should also fix this. Regards, -- Sébastien Miquel
Re: Root heading when exporting sub-trees
Hi, Michael Dauer writes: When I export a subtree I normally want to produce a document for the topic of the subtree. So I would expect that the contents of the subtree would be exported with the heading as title (and maybe file name) and the children promoted to level 1. This is the expected behaviour (except for the file name), and what I get when I run C-c C-e C-s l o. What I receive is something like this: [...] The whole first level of this outline is pointless. Looking at the code, I don't understand how you can get this outcome. Regards, -- Sébastien Miquel
Re: [PATCH] Add support for $…$ latex fragments followed by a dash
Hi, Ihor Radchenko writes: We can theoretically make a change to support "-", but then it will be logical to support $i$th as well. (If we don't some users will still be confused after trying to write $i$th and then not getting the expected results). I disagree. 1. The $…$- pattern is also used for other common constructions, such as $n$-dimensional, $K$-lipschitz, etc. As for $n$−th vs $n$th, both are commonly used. In french, $n$− is the correct one. 2. It does not logically follow that we should support $i$th as well, since, as you point out, it'd be impossible. One argument for the patch is that is it very simple. 3. The $n$th construction failing is not as confusing. One understands quickly what the limitation is, and several workarounds are available, whereas there's no good reason for the $n$− limitation, and it's harder to think of a workaround. I should mention that the zero-width space character can be used to work around both limitations. Given the raised concerns, may we solve the issue with too verbose \(...\) unambiguous syntax using the following approach: 1. Fontify \(...\) replacing the brackets with a single character. For example: \(...\) -> ⁅...⁆ 2. Provide convenient way to input \(\) brackets through electric-pair-mode or trough org-cdlatex-mode. If the $…$ syntax were to be deprecated, this would be a nice addition, indeed. As a user, I find it quite satisfactory (with some added utility to easily switch between the \(…\) and \[…\] syntax). Some possible drawbacks : - are the display hacks scalable in a large document, with many LaTeX snippets ? - this feature may still be hard to discover, turn on and use by users more concerned with mathematical content and less familiar with emacs features such as fontification, automatic insertion of complex delimiters and whatnot. - hiding the syntax feels a bit weird, although it is already done with emphasis markers. With respect to the possible deprecation of the $…$ syntax, the drawbacks and complexity of this alternative should be weighted against those of the current $…$ syntax, but no one has really spelled out what the latter are. We're trading complexity here for complexity there, fixing the false positives (but how common are they ?) and the false negatives (which can be an annoyance while writing a snippet). Thank you for bringing this up, Regards, -- Sébastien Miquel
Re: [PATCH] Add support for $…$ latex fragments followed by a dash
Hi, Tom Gillespie writes: The change is local and minor. We can't know that. I meant that the change to the syntax would be minor and local, with respect to the linked syntax document. #+begin_src org I spent $20 on food and was paid$-10 dollars by friends so I am down $10. #+end_src [...] #+begin_src org Text a $A_BASH_VAR Text b some-$-lisp-var #+end_src The proposed change would break any file with a pattern like this. As you say, your first example is a typo. As for the second example, it's a very uncommon pattern, and if such variable names occur in a document, they should either be inside src blocks, or inside verbatim or code markers. In both case, there's no breakage with respect to parsing, export and tangling. The fontification may fail though. It wont fail if your src blocks are fontified natively, and the fontification of $…$ can be globally disabled. We have no way of seeing every org file that users have written so we don't know the extent of the impact, and thus have to assume that there would be some impact. Making such a change with an unknown blast radius in the midst of considering removing support for that syntax altogether is inviting disaster. We can make an educated guess. It is quite likely that this change will fix more documents than it breaks. Hardly a disaster. Regards, -- Sébastien Miquel
Re: [PATCH] Add support for $…$ latex fragments followed by a dash
Hi, Tom Gillespie writes: Unfortunately this falls into the realm of changes to syntax. The current behavior is not a bug and is working as specified because hyphen minus (U+002D) does not count as punctuation for the purposes of org syntax. We should specify which chars count as punctuation in the syntax doc. As noted by Eric \(\) has no such restrictions. Fromhttps://orgmode.org/worg/dev/org-syntax.html#Entities_and_LaTeX_Fragments POST is any punctuation (including parentheses and quotes) or space character, or the end of line. With this patch, I also propose to change the specification accordingly. The change is local and minor. Regards, -- Sébastien Miquel
Re: Poor org-babel-tangle-file performance with more than 100 trivial noweb-references
Hi, pareto optimal writes: Using =emacs -Q= to tangle org files with more than over 100 noweb-refs gets slow fast. I can reproduce the slow down with my config. The culprit is ~org-element--cache-verify-element~. Significantly decreasing =org-element--cache-self-verify-frequency= yields a 5x speedup. Perhaps the frequency of the second : (< (random 1000) (* 1000 org-element--cache-self-verify-frequency)) call in ~org-element--cache-verify-element~ should be decreased. Regards, -- Sébastien Miquel
Re: [PATCH] Add support for $…$ latex fragments followed by a dash
Hi, Eric S Fraga writes: But is not necessary (and further complicates the issue of support $...$ in org as recently discussed on this list) as you can simply type \(n\)-th? What complication are you referring to, precisely ? The patch is fairly trivial, and a similar extension was already implemented by Nicolas in 2017[1]. Yes, the $…$ syntax is redundant, but I do not think it follows that this change is unnecessary. This patch should have no bearing on the possible deprecation of the $…$ syntax. [1]: https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c0369a798470763f8f3c69cf2079c3a194635feb Regards, -- Sébastien Miquel
[PATCH] Add support for $…$ latex fragments followed by a dash
Hi,
The attached patch adds support for $…$ latex fragments followed by a
dash, such as $n$-th.
This pattern is quite common, and the issue was mentionned by Rudolf
Adamkovič, here: https://list.orgmode.org/m2mtjvefrf@me.com/.
This extension of the syntax doesn't conflict with the use of $'s in
table formulas, or for currency, AFAICT.
Regards,
--
Sébastien Miquel
From b023fff129a5cc3b1f12b9f170f2e018dc34d237 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?=
Date: Sun, 23 Jan 2022 13:28:03 +0100
Subject: [PATCH] =?UTF-8?q?org-element:=20Support=20$=E2=80=A6$=20LaTeX=20?=
=?UTF-8?q?fragments=20followed=20by=20a=20dash?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* lisp/org-element.el (org-element-latex-fragment-parser):
* lisp/org.el (org-latex-regexps): Allow a dash right after a
$…$ fragment.
* testing/lisp/test-org-element.el (test-org-element/latex-fragment-parser):
Add test.
Allows such uses as `$n$-th' or `$n$-dimensional'.
---
lisp/org-element.el | 2 +-
lisp/org.el | 4 ++--
testing/lisp/test-org-element.el | 4
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/lisp/org-element.el b/lisp/org-element.el
index b82475a14..40a604578 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -3416,7 +3416,7 @@ Assume point is at the beginning of the LaTeX fragment."
(not (memq (char-before (match-beginning 0))
'(?\s ?\t ?\n ?, ?.)))
(looking-at-p
- "\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|'\\|$\\)")
+ "\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|'\\|-\\|$\\)")
(point)
(post-blank
(if (not after-fragment) (throw 'no-object nil)
diff --git a/lisp/org.el b/lisp/org.el
index 2d439cd05..3a164ee77 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -629,8 +629,8 @@ An entry can be toggled between COMMENT and normal with
'(("begin" "^[ \t]*\\(begin{\\([a-zA-Z0-9\\*]+\\)[^\000]+?end{\\2}\\)" 1 t)
;; ("$" "\\([ \t(]\\|^\\)\\(\\(\\([$]\\)\\([^ \t\n,.$].*?\\(\n.*?\\)\\{0,5\\}[^ \t\n,.$]\\)\\4\\)\\)\\([ \t.,?;:'\")]\\|$\\)" 2 nil)
;; \000 in the following regex is needed for org-inside-LaTeX-fragment-p
-("$1" "\\([^$]\\|^\\)\\(\\$[^ \t\r\n,;.$]\\$\\)\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|\000\\|'\\|$\\)" 2 nil)
-("$" "\\([^$]\\|^\\)\\(\\(\\$\\([^ \t\n,;.$][^$\n\r]*?\\(\n[^$\n\r]*?\\)\\{0,2\\}[^ \t\n,.$]\\)\\$\\)\\)\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|\000\\|'\\|$\\)" 2 nil)
+("$1" "\\([^$]\\|^\\)\\(\\$[^ \t\r\n,;.$]\\$\\)\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|\000\\|'\\|-\\|$\\)" 2 nil)
+("$" "\\([^$]\\|^\\)\\(\\(\\$\\([^ \t\n,;.$][^$\n\r]*?\\(\n[^$\n\r]*?\\)\\{0,2\\}[^ \t\n,.$]\\)\\$\\)\\)\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|\000\\|'\\|-\\|$\\)" 2 nil)
("\\(" "([^\000]*?)" 0 nil)
("\\[" "\\[[^\000]*?\\]" 0 nil)
("$$" "\\$\\$[^\000]*?\\$\\$" 0 nil))
diff --git a/testing/lisp/test-org-element.el b/testing/lisp/test-org-element.el
index 6d7376a96..2055e3a7b 100644
--- a/testing/lisp/test-org-element.el
+++ b/testing/lisp/test-org-element.el
@@ -1776,6 +1776,10 @@ e^{i\\pi}+1=0
(eq 'latex-fragment
(org-test-with-temp-text "$a$'"
(org-element-type (org-element-context)
+ (should
+ (eq 'latex-fragment
+ (org-test-with-temp-text "$a$-"
+ (org-element-type (org-element-context)
;; Test forbidden characters inside $...$.
(should-not
(eq 'latex-fragment
--
2.34.1
Re: Depreciating TeX-style LaTeX fragments (was: Org Syntax Specification)
Hi, With respect to readability, I only mean to point out that the $…$ syntax is one less character, and that the \(\) characters are quite overloaded. this is a good opportunity to point out that $/$$ are very much second class citizens in LaTeX now, no matter what you may see in old documents. The posts that you quote are 10 years old. As per [0] (2020), there will be no LaTeX3. Nor is it only old documents that use the $…$ syntax : looking for learning ressources (see [1]), everything that I find uses it. That includes The Not So Short Introduction to LaTeX [2] (2021) and https://en.wikibooks.org/wiki/LaTeX/Mathematics. Although I have no evidence of this, my expectation is that the majority of tex users use the $…$ syntax (it is in fact widely used outside of tex: in most markdown flavors and texmacs for example). I also expect that a significant proportion of tex users are not aware of the \(…\) syntax. I think here of users that are less tech literate than most of this mailing list. Regards, [0]: https://www.latex-project.org/publications/2020-FMi-TUB-tb128mitt-quovadis.pdf [1]: https://tex.stackexchange.com/questions/11/what-are-good-learning-resources-for-a-latex-beginner [2]: https://ctan.tetaneutral.net/info/lshort/english/lshort.pdf -- Sébastien Miquel
Re: Org Syntax Specification
Hi, The new document seems much clearer. It makes a nice complement to the manual and we should definitely lose the (draft). Thank you Timothy for the work. Lastly, having spent a while looking at the syntax, I’m wondering if we should take this opportunity to mark some of the syntactic elements we’ve become less happy with as *(depreciated)*. I’m specifically thinking of the TeX-style LaTeX fragments which have been a bit of a pain. To quote Nicolas in org-syntax.org: It would introduce incompatibilities with previous Org versions, but support for |$...$| (and for symmetry, |$$...$$|) constructs ought to be removed. They are slow to parse, fragile, redundant and imply false positives. — ngz This quote has been mentioned a few times lately, and no one has yet spoken in favor of the $…$ syntax, so I'll have a quick go. It is easier to use, easier to read and more commonly used (and known) in tex documents (a quick web search for sample tex documents confirms the latter). Removing this syntax would make org slightly harder to pick up, with respect to writing scientific documents. As for the listed shortcomings, I don't think we know whether its slowness is significant and false positives can be avoided by using the \dollar entity (possibly ?). In my own use, the only usability issue I can think of is false negatives while writing : inserting a space or other such characters at the end of a snippet removes the fontification (I solve this by modifying the fontification regexps). Regards, -- Sébastien Miquel
[PATCH] Add :noweb-prefix and :noweb-trans babel header arguments
Hi,
The attached patch adds support for two new babel header arguments:
=:noweb-prefix= and =:noweb-trans=.
=:noweb-prefix= can be set to =no= to disable the noweb prefix
behaviour, where prefix characters are repeated when expanding a
multiline noweb reference.
=:noweb-trans= can be set to =prin1-to-string= to insert a lisp string
representing the content of the referenced src block.
The goal is to allow one to use, say, a LaTeX src block to represent
some LaTeX snippet to be tangled into a string in some lisp (or other)
code. This isn't possible currently, and one has to manually string
escape the LaTeX code.
As an example, the following two blocks
#+BEGIN_SRC LaTeX :tangle no :noweb-ref nw
\usepackage{…}
\usepackage{…}
#+END_SRC
#+BEGIN_SRC emacs-lisp :noweb yes :tangle yes :noweb-prefix no
:noweb-trans prin1-to-string
(setq latex-header <>)
#+END_SRC
would tangle to
#+BEGIN_SRC emacs-lisp
(setq latex-header "\\usepackage{…}
\\usepackage{…}")
#+END_SRC
I've left undocumented the possibility of setting =:noweb-trans= to
another function. I wonder if anyone can think of some other use.
Regards,
--
Sébastien Miquel
From 66f271225767d07e12bcc73a1ddbadf038d245fa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?=
Date: Mon, 6 Sep 2021 18:45:42 +0200
Subject: [PATCH] ob-core.el: Add `:noweb-prefix`, `:noweb-trans` babel header
arguments
* lisp/ob-core.el (org-babel-expand-noweb-references): Add support for
`noweb-prefix' header argument, to not repeat the prefix characters
when expanding a noweb reference. Add support for `noweb-trans' header
argument, to apply a function to the noweb content upon
expansion.
(org-babel-common-header-args-w-values):
(org-babel-safe-header-args): Add `noweb-prefix' and `noweb-trans' values.
* doc/org-manual.org: Document `noweb-prefix' and `noweb-trans' babel header
arguments.
* etc/NEWS: Document `:noweb-prefix' and `:noweb-trans'.
---
doc/org-manual.org | 34 ++
etc/ORG-NEWS | 9 +
lisp/ob-core.el| 26 --
3 files changed, 59 insertions(+), 10 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index b4c20f252..d7b1c4203 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -18554,10 +18554,11 @@ Note that the expansion now contains the results of the code block
: 100
Noweb insertions honor prefix characters that appear before the noweb
-syntax reference. This behavior is illustrated in the following
-example. Because the =<>= noweb reference appears behind the
-SQL comment syntax, each line of the expanded noweb reference is
-commented. With:
+syntax reference. This behavior can be turned off by setting the
+=noweb-prefix= header argument to =no= and is illustrated in the
+following example. Because the =<>= noweb reference appears
+behind the SQL comment syntax, each line of the expanded noweb
+reference is commented. With:
#+begin_example
,#+NAME: example
@@ -18626,6 +18627,31 @@ else:
print('do things when false')
#+end_example
+The header argument =noweb-trans= can be set to =prin1-to-string= to
+insert a lisp string representing the content of the referenced src
+block. With:
+
+#+begin_example
+,#+NAME: latex-header
+,#+BEGIN_SRC latex
+ \usepackage{amsmath}
+,#+END_SRC
+#+end_example
+
+#+texinfo: @noindent
+this code block:
+
+#+begin_example
+,#+BEGIN_SRC elisp :noweb yes
+ (setq header <>)
+,#+END_SRC
+#+end_example
+
+#+texinfo: @noindent
+expands to:
+
+: (setq header "\\usepackage{amsmath}")
+
When in doubt about the outcome of a source code block expansion, you
can preview the results with the following command:
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 335db4139..6fa808645 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -63,6 +63,15 @@ list of various table options (between brackets in LaTeX export),
since certain tabular environments, such as longtblr of the
tabularray LaTeX package, provides this structure.
+*** New =:noweb-prefix= and =:noweb-trans= babel header arguments
+
+=:noweb-prefix= can be set to =no= to prevent the prefix characters
+from being repeated when expanding a multiline noweb reference.
+
+=:noweb-trans= can be set to =prin1-to-string=. Noweb reference
+therein will be expanded to an elisp string representation of their
+content.
+
** New functions and changes in function arguments
*** New function ~org-element-cache-map~ for quick mapping across Org elements
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 239a57f96..1d5d1bedc 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -411,6 +411,8 @@ then run `org-babel-switch-to-session'."
(noweb . ((yes no tangle no-export strip-export)))
(noweb-ref . :any)
(noweb-sep . :any)
+(noweb-prefix . ((no yes)))
+(noweb-trans . ((prin1-to-string)))
(output-dir . :any)
(padline . ((yes no)))
(post . :any)
@@ -436,9 +438,10 @@ specific h
Re: `org-fill-paragraph' (`M-q') in Org Mode source blocks
Fabio Natali writes: Thanks for getting back to me and thank you very much for the code snippet, which I think I'm going to integrate in my configuration. Thank you for the report. With regard to the snippet, It seems the advice function needs ~( justify region)~ as arguments rather than (). I'd be curious to hear from other fellow Org Moders. If this is a relatively common problem and there's interest around it, maybe we could think of a fix directly in the code base. The best way to get it done is to post a patch to the list. If it doesn't break a legitimate existing behaviour, It should get applied. I'll probably do so eventually, or you could, if you feel so inclined. Perhaps one difficulty is to deal with the case where the org-babel call errors out, say if there's no mode to edit the src code in. -- Sébastien Miquel
Re: [PATCH] Bug: Incorrect indentation in Org Babel list output with multiline text [9.4.4 (release_9.4.4 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]
Hi, Vikas Kumar writes: Here is a patch with the fix. Thank you for the patch. I'm just adding the [PATCH] cookie, so that this shows up on https://updates.orgmode.org/. A maintainer will eventually get back to you, but it may take a while (couple of months at most). Regards, -- Sébastien Miquel
Re: `org-fill-paragraph' (`M-q') in Org Mode source blocks
Hi, Fabio Natali writes: Is there anything obvious that you think I'm missing here? Is anyone able to replicate the above behaviour and, if so, do you also find it slightly problematic? Any thoughts and feedback on the above will be greatly appreciated.:) It's not just you. I think org-fill-paragraph should try to act natively if called from inside a src block. As it happens, I've recently added the following advice to my init file. (defun my-org-fill-paragraph-natively-maybe () (let* ((element (save-excursion (beginning-of-line) (org-element-at-point-no-context))) (type (org-element-type element))) (if (and (eq type 'src-block) (> (line-beginning-position) (org-element-property :post-affiliated element)) (< (line-beginning-position) (org-with-point-at (org-element-property :end element) (skip-chars-backward " \t\n") (line-beginning-position (progn (org-babel-do-in-edit-buffer (fill-paragraph)) nil) t))) (advice-add 'org-fill-paragraph :before-while #'my-org-fill-paragraph-natively-maybe) Regards, -- Sébastien Miquel
Re: bug#52771: 29.0.50; org-fill-paragraph does not work for several plain lists
Hi, Kyle Meyer writes: Rudolf Adamkovič writes: Reproduction steps: 1. start "emacs -Q" 2. type "C-x C-f" and "test.org" and RET 3. type the following: - one two - three four 4. mark all with "C-x h" 5. type "M-q" to fill Actual: - one two - three four Expected: - one two - three four Note that this issue is fixed by the patch proposed at https://list.orgmode.org/041ca43d-2efb-db1e-76ab-7c15af088...@posteo.eu/ Regards, -- Sébastien Miquel
Re: Patch to align baseline of latex fragments and surrounding text
Matt Huszagh writes:
I couldn't get ~org--match-text-baseline-ascent~ to compute the
ascent : the ~xml-get-attribute~ call returns
: ("-16.945024" "12.153473" "16.148855" "8.064997")
which gives an ascent < -100, and the code then defaults to 'center.
I'd need to know more about your setup for generating latex
fragments. Did you follow all the directions in
org--match-text-baseline-ascent? How is your org-format-latex-header
set? In particular, are you using \documentclass[preview]{standalone}?
If you can provide me with the TeX file used to generate the fragment,
as well as the SVG file you get as a result, that would be helpful too.
My mistake. For some reason, I had thought that
=\documentclass[preview]{standalone}= was used by default for LaTeX
previews. Setting it as described in your patch, it now works
properly, even with the default value of =dvisvgm=.
If there are no drawbacks, perhaps this behaviour should be the
default. Otherwise, it should at least be easier to toggle.
I didn't attempt to make this the default because it requires a specific
setup, which is also different from the current default setup in other
respects. Most importantly, it requires using the standalone document
class, though I believe article is used at the moment.
To make this behavior easier to toggle, you could
1. Change the default value of =org-format-latex-header=. The
=standalone= class makes sense, but I don't know if that might
break things.
2. Specify the =:latex-header= of the default =dvisvgm= option. Same
caveat applies.
3. Add a =dvisvgm-with-ascent= option to the default value of
=org-preview-latex-process-alist=.
Instead of the new variable =org-latex-fragment-overlay-ascent=,
perhaps the function used to compute the ascent could be provided as
another property, such as =:ascent=, added to the relevant options in
=org-preview-latex-process-alist=. It seems to make more sense since
it only applies to svg output, and it makes it easier to have this
behavior as default. It would require =org--make-preview-overlay= to
take the ascent as an additional argument.
Please note that I am not a maintainer, these are just a few thoughts.
I do hope your work can be applied and that LaTeX fragments can be
properly aligned by default.
You should add [PATCH] to the subject of your mail, so that it gets
listed at https://updates.orgmode.org/ and not forgotten. A maintainer
will reply eventually, but it might take up to a few months.
Regards,
--
Sébastien Miquel
Re: Patch to align baseline of latex fragments and surrounding text
Hi,
Matt Huszagh writes:
I feel that maybe it would be useful to attach screenshots to show the
improvement from this patch? Anyway, I've attached two images: one with
the correct baseline alignment to surrounding text and the other with
the current, incorrect, baseline alignment.
I think a lot of people would like this functionality. It looks much
better than the current behavior.
This looks great indeed but I've failed to reproduce in my
environment.
I couldn't get ~org--match-text-baseline-ascent~ to compute the
ascent : the ~xml-get-attribute~ call returns
: ("-16.945024" "12.153473" "16.148855" "8.064997")
which gives an ascent < -100, and the code then defaults to 'center.
The options described in your =my-dvisvgm= seem outdated, you can
check the latest default value of =dvisvgm= : =use-xcolor= is
deprecated and a =:image-size-adjust= property is provided for the
images to be sized properly. Are the arguments =--no-fonts= and
=--exact-bbox= necessary ?
If there are no drawbacks, perhaps this behaviour should be the
default. Otherwise, it should at least be easier to toggle.
Can something similar be done with =dvipng= ?
Regards,
--
Sébastien Miquel
Re: [PATCH] org-src.el: add option `org-src-native-defun-movements'
Hi, Thank you for having a look. Tim Cross writes: This also seems like an edge case and I'm not convinced yet another option is justified. Why have eilisp in org blocks rather than an emacs-lisp block? By org src blocks I meant an org emacs-lisp src block. The point of the patch is to be able to eval-defun some lisp code in an emacs-lisp src block from the org-buffer. As this is a breaking change, it should not be on by default. Currently eval-defun errors out, and fixing that will break things sooner or later, I think. I do not mind updating the patch to set the new option to nil by default, although I'll wait for a second opinion on this. Regards, -- Sébastien Miquel
[PATCH] org-src.el: add option `org-src-native-defun-movements'
Hi, The attached patch adds a new option ~org-src-native-defun-movements~ that makes ~beginning-of-defun~, ~end-of-defun~ and ~eval-defun~ work natively when called from inside an org src block : those functions are called from an org src edit buffer, in the appropriate language mode. Without this patch, calling =eval-defun= on elisp code fails. With this option set to t by default, this is a breaking change. To get to the beginning/end of a src block you'd have to call ~org-backward-element~ or ~org-forward-element~ directly, instead of ~beginning-of-defun~. Or you could disable the new behaviour by setting ~org-src-native-defun-movements~ to nil. Regards, -- Sébastien Miquel From 51675d8bbea54db7daf3dcc88a77ccad5174854f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Fri, 27 Aug 2021 21:41:29 +0200 Subject: [PATCH] org-src.el: add option `org-src-native-defun-movements' * lisp/org-src.el (org-src-native-defun-movements): New option. If t, `beginning-of-defun', `end-of-defun' and `eval-defun' act natively when called from inside a src block. (org-beginning-of-defun): (org-end-of-defun): New functions. If `org-src-native-defun-movements' is t and point is in a src block, call `beginning-of-defun' or `end-of-defun' from the src edit buffer. The main goal is to make `eval-defun' work from the org buffer. For this to work, if point is at the beginning of an #+end_src line, `org-beginning-of-defun' has to work natively. To get to the beginning of the src block, call `org-backward-element` instead. --- etc/ORG-NEWS| 20 ++ lisp/org-src.el | 7 +++ lisp/org.el | 54 ++--- 3 files changed, 74 insertions(+), 7 deletions(-) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index eb5a5d40d..379870d44 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -60,6 +60,26 @@ list of various table options (between brackets in LaTeX export), since certain tabular environments, such as longtblr of the tabularray LaTeX package, provides this structure. +*** ~beginning-of-defun~ and ~eval-defun~ now work natively in src blocks + +To get to the beginning or end of a src block, use +~org-backward-element~ and ~org-forward-element~ instead, or disable +this new behaviour by setting ~org-src-native-defun-movements~ to nil. + +** New options + +*** New option =org-src-native-defun-movements= + +This option, t by default, makes ~beginning-of-defun~, ~end-of-defun~ +and ~eval-defun~ work natively inside src blocks : the corresponding +function is called from an org src block edit buffer in the language +specific mode. + +For ~eval-defun~ to work natively from the org buffer, if point is at +the beginning of an #+end_src line, `org-beginning-of-defun` will work +natively as well. To get to the beginning of the src block, call +`org-backward-element` instead. + ** New functions and changes in function arguments *** New function ~org-element-cache-map~ for quick mapping across Org elements diff --git a/lisp/org-src.el b/lisp/org-src.el index 46fed052d..8feced080 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -246,6 +246,13 @@ green, respectability. :package-version '(Org . "9.4") :group 'org-babel) +(defcustom org-src-native-defun-movements t + "If non-nil, the effect of `beginning-of-defun' and +`end-of-defun' in a code block is as if they were issued in the +language major mode buffer." + :type 'boolean + :package-version '(Org . "9.6") + :group 'org-babel) ;;; Internal functions and variables diff --git a/lisp/org.el b/lisp/org.el index ec59ddf44..1ff0d6f87 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -4892,13 +4892,8 @@ The following commands are available: org-element-use-cache) (org-persist-read 'org-element--cache (current-buffer))) ;; Beginning/end of defun - (setq-local beginning-of-defun-function 'org-backward-element) - (setq-local end-of-defun-function - (lambda () - (if (not (org-at-heading-p)) - (org-forward-element) - (org-forward-element) - (forward-char -1 + (setq-local beginning-of-defun-function 'org-beginning-of-defun) + (setq-local end-of-defun-function 'org-end-of-defun) ;; Next error for sparse trees (setq-local next-error-function 'org-occur-next-match) ;; Make commit log messages from Org documents easier. @@ -21525,6 +21520,51 @@ Move to the previous element at the same level, when possible." (<= (org-element-property :end prev) beg)) (goto-char (org-element-property :begin prev))) +(defun org-beginning-of-defun () + "If point is in a src block and `org-src-native-defun-movements' +is non-nil, call `beginning-of-defun' in the src block edit +buffer, otherwise call `org-backward-element'." + (interactive) + (if (and org-src-native-defun-movements + (let* ((element (save-excursion (beginning-of-line) +
Re: [patch] fix ox-latex async export bug
Hi, Rasmus Pank Roulund writes: This is most likely due to native compilation which compiles the unquoted lambda. Once compiled, it (presumably) fails to be passed to the external emacs process. Ah, interesting. Is this a bug or a feature? I think the bug's with org-mode. As I explain elsewhere in the thread, this lambda is to be treated as data, and written to a file to be executed by the external emacs instance. It should always have been quoted (naming it happens to work also). Regards, -- Sébastien Miquel
[PATCH] org.el: Fix the filling of regions containing lists
Hi, The attached patch fixes the following issues with the functions =fill-region= and =fill-paragraph=, when called with an active region containing a list. In the examples, replace 'long line' by long lines to be filled. + Calling =fill-region= on a region which contains a list with single line items (such as the one below) breaks the list structure. - long line - long line + Calling =fill-region= on a region with a list such as the one below doesn't fill the list - short line short line - short line short line + Calling =fill-paragraph= on a region containing a list such as the one below doesn't fill the first item - long line - long line - long line + Calling =fill-paragraph= on a region containing a list such as the one below doesn't fill the list - long line - long line - short line Regards, -- Sébastien Miquel From 6c60e8e43e39074fa87da2f0ed272a69a6793862 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Sat, 6 Nov 2021 22:41:20 +0100 Subject: [PATCH] org.el: Fix the filling of regions containing lists * lisp/org.el (org-setup-filling): Set fill-forward-paragraph-function. (org--single-lines-list-is-paragraph): New internal variable. Whether a list with single lines items should be considered a single paragraph. (org--paragraph-at-point): use org--single-lines-list-is-paragraph. (org-fill-paragraph): When an active region contains a list ensure every item get filled. * testing/lisp/test-org.el (test-org/fill-paragraph): (test-org/fill-region): Test behaviour of fill-paragraph and fill-region with an active region containing a list. When filling paragraphs in a region, do not treat a list with single lines items as a single paragraph. --- lisp/org.el | 19 +++ testing/lisp/test-org.el | 41 2 files changed, 56 insertions(+), 4 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 025513e7a..17046f391 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -19629,6 +19629,8 @@ assumed to be significant there." ;; `org-setup-filling' installs filling and auto-filling related ;; variables during `org-mode' initialization. +(defvar org--single-lines-list-is-paragraph) ; defined later + (defun org-setup-filling () (require 'org-element) ;; Prevent auto-fill from inserting unwanted new items. @@ -19644,6 +19646,10 @@ assumed to be significant there." (setq-local paragraph-start paragraph-ending) (setq-local paragraph-separate paragraph-ending)) (setq-local fill-paragraph-function 'org-fill-paragraph) + (setq-local fill-forward-paragraph-function + (lambda ( arg) +(let ((org--single-lines-list-is-paragraph nil)) + (org-forward-paragraph arg (setq-local auto-fill-inhibit-regexp nil) (setq-local adaptive-fill-function 'org-adaptive-fill-function) (setq-local normal-auto-fill-function 'org-auto-fill-function) @@ -19873,9 +19879,11 @@ filling the current element." (progn (goto-char (region-end)) (skip-chars-backward " \t\n") - (while (> (point) start) - (org-fill-element justify) - (org-backward-paragraph))) + (let ((org--single-lines-list-is-paragraph nil)) +(while (> (point) start) + (org-fill-element justify) + (org-backward-paragraph) + (skip-chars-backward " \t\n" (goto-char origin) (set-marker origin nil (t @@ -21218,6 +21226,9 @@ It also provides the following special moves for convenience: ;; Return moves left. arg)) +(defvar org--single-lines-list-is-paragraph t + "Treat plain lists with an item every line as a whole paragraph") + (defun org--paragraph-at-point () "Return paragraph, or equivalent, element at point. @@ -21279,7 +21290,7 @@ Function may return a real element, or a pseudo-element with type (while (memq (org-element-type (org-element-property :parent l)) '(item plain-list)) (setq l (org-element-property :parent l))) - (and l + (and l org--single-lines-list-is-paragraph (org-with-point-at (org-element-property :post-affiliated l) (forward-line (length (org-element-property :structure l))) (= (point) (org-element-property :contents-end l))) diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el index 056ea7d87..4375456da 100644 --- a/testing/lisp/test-org.el +++ b/testing/lisp/test-org.el @@ -765,8 +765,49 @@ (push-mark (point) t t) (goto-char (point-max)) (call-interactively #'org-fill-paragraph) + (buffer-string) + ;; Fill every list item in a region + (should + (equal "\n- 2345678\n 9\n- 2345678\n 9" + (org-test-with-temp-text "\n- 2345678 9\n- 2345678 9" + (let ((fill-column 10)) + (transient-mark-mode 1) + (push-mark (point-min) t t) +
Re: [PATCH] Fontification for inline src blocks
Hi, Timothy writes: Pushed . Sorry for the late reply, but isn't there a =message= call leftover from debugging ? Regards, -- Sébastien Miquel
Re: [patch] fix ox-latex async export bug
Hi, Nicolas Goaziou writes: This is not really the same fix. Indeed, but I tested it and it does work. You're quoting a lambda, which should not be required if the problem disappeared. IOW, the true fix probably belong in the `org-export-async-start' function. What happens is as follows 1. This lambda is passed as the =post-process= variable of =org-export-to-file=. 2. Which converts it to code using =`(funcall ',post-process)= 3. Which =org-export-async-start= writes to a file, to be executed by the external emacs process. I think native compilation compiles the lamdba in =org-latex-export-to-pdf= and that there is no way to get back this original lambda (the code) from within =org-export-to-file= or =org-export-async-start=. Quoting the lambda prevents this compilation. My understanding of elisp and the native compilation business is quite superficial, so this may be wrong. Regards, -- Sébastien Miquel
Re: [patch] fix ox-latex async export bug
Hi, Nicolas Goaziou writes: I don’t really understand why this bug happens to be honest. The patch is already an improvement, but the beast is still lurking, indeed. This is most likely due to native compilation which compiles the unquoted lambda. Once compiled, it (presumably) fails to be passed to the external emacs process. Attached is a patch that applies the same fix where affected. Regards, -- Sébastien Miquel From 35ae093113d9a04a99b55f0747848b373a7463f3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Mon, 29 Nov 2021 09:54:33 +0100 Subject: [PATCH] ox: Fix async export with native compilation * lisp/ox-beamer.el (org-beamer-export-to-pdf): * lisp/ox-icalendar.el (org-icalendar-export-to-ics): * lisp/ox-koma-letter.el (org-koma-letter-export-to-pdf): * lisp/ox-man.el (org-man-export-to-pdf): * lisp/ox-texinfo.el (org-texinfo-export-to-info): Quote lambda. Quote or name lambdas to prevent their compilation into anonymous functions which cannot be passed to the external async emacs process. --- lisp/ox-beamer.el | 2 +- lisp/ox-icalendar.el | 4 ++-- lisp/ox-koma-letter.el | 2 +- lisp/ox-man.el | 2 +- lisp/ox-texinfo.el | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/lisp/ox-beamer.el b/lisp/ox-beamer.el index c9a67f891..3bfcd01d4 100644 --- a/lisp/ox-beamer.el +++ b/lisp/ox-beamer.el @@ -1059,7 +1059,7 @@ Return PDF file's name." (let ((file (org-export-output-file-name ".tex" subtreep))) (org-export-to-file 'beamer file async subtreep visible-only body-only ext-plist - (lambda (file) (org-latex-compile file) + #'org-latex-compile))) ;;;###autoload (defun org-beamer-select-environment () diff --git a/lisp/ox-icalendar.el b/lisp/ox-icalendar.el index 0a682c7c8..68c5679ea 100644 --- a/lisp/ox-icalendar.el +++ b/lisp/ox-icalendar.el @@ -888,8 +888,8 @@ Return ICS file name." (org-export-to-file 'icalendar outfile async subtreep visible-only body-only '(:ascii-charset utf-8 :ascii-links-to-notes nil) - (lambda (file) - (run-hook-with-args 'org-icalendar-after-save-hook file) nil + '(lambda (file) + (run-hook-with-args 'org-icalendar-after-save-hook file) nil ;;;###autoload (defun org-icalendar-export-agenda-files ( async) diff --git a/lisp/ox-koma-letter.el b/lisp/ox-koma-letter.el index 6a895a6a2..978e4e41f 100644 --- a/lisp/ox-koma-letter.el +++ b/lisp/ox-koma-letter.el @@ -982,7 +982,7 @@ Return PDF file's name." (org-koma-letter-special-contents)) (org-export-to-file 'koma-letter file async subtreep visible-only body-only ext-plist - (lambda (file) (org-latex-compile file) + #'org-latex-compile))) (provide 'ox-koma-letter) diff --git a/lisp/ox-man.el b/lisp/ox-man.el index 6d3476cda..9a1f00f35 100644 --- a/lisp/ox-man.el +++ b/lisp/ox-man.el @@ -1117,7 +1117,7 @@ Return PDF file's name." (let ((outfile (org-export-output-file-name ".man" subtreep))) (org-export-to-file 'man outfile async subtreep visible-only body-only ext-plist - (lambda (file) (org-latex-compile file) + #'org-latex-compile))) (defun org-man-compile (file) "Compile a Groff file. diff --git a/lisp/ox-texinfo.el b/lisp/ox-texinfo.el index b0125894a..734c8a4f3 100644 --- a/lisp/ox-texinfo.el +++ b/lisp/ox-texinfo.el @@ -1701,7 +1701,7 @@ Return INFO file's name." (org-export-coding-system org-texinfo-coding-system)) (org-export-to-file 'texinfo outfile async subtreep visible-only body-only ext-plist - (lambda (file) (org-texinfo-compile file) + #'org-texinfo-compile))) ;;;###autoload (defun org-texinfo-publish-to-texinfo (plist filename pub-dir) -- 2.34.1
[BUG] org-element-at-point returns wrong element
Hi, With point at the bol of the empty line after the keyword and before the heading at the end of this mail, =org-element-at-point= returns the headline element. It used to (a month ago, before all the caching) return the keyword. This breaks =org-element-context= which errors out when called from the same point. Regards, #+LATEX_CLASS: my-class * Head1 * Head2 -- Sébastien Miquel
[PATCH] org.el (org-display-inline-image--width): Small fix
Hi, The variable display-line-numbers-width is nil by default. Regards, -- Sébastien Miquel From 2e306750caff0474aa9a6443c7d7eb68e3aca83b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Sat, 23 Oct 2021 13:28:59 +0200 Subject: [PATCH] org.el (org-display-inline-image--width): Small fix --- lisp/org.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index 474171b55..3140c4d1f 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -16867,7 +16867,7 @@ buffer boundaries with possible narrowing." (/ (or (and (bound-and-true-p visual-fill-column-mode) (or visual-fill-column-width auto-fill-function)) (when auto-fill-function fill-column) - (- (window-text-width) display-line-numbers-width)) + (- (window-text-width) (or display-line-numbers-width 0))) (float (window-total-width) width))) ((numberp org-image-actual-width) -- 2.33.1
Re: [PATCH] Re: Bug: org-edit-special indents inline latex [9.5 (nil @ /home/david/.emacs.d/.local/straight/build-27.2/org-mode/)]
Hi Bastien, Bastien writes: Sébastien, have you been able to test this patch heavily and is it still needed, or has it been made somehow irrelevant? (I see it does apply well on the bugfix branch, but not on main.) Thanks for any feedback, I've rebased the patch on main. It is still relevant (Ihor and I have provided reproducers earlier in the thread). I had done some testing, and some more recently. The patch only affects latex-fragments and org entities to be edited which do not need to start at a beginning of line (latex-fragments, inline src blocks, footnote definitions). Regards, -- Sébastien Miquel From b80124aa6edbd3b6992817dd8c37253705c82ae3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Mon, 30 Aug 2021 23:18:41 +0200 Subject: [PATCH] org-src.el: Fix special editing of LaTeX fragments * lisp/org-macs.el (org-do-remove-indentation): Add optional argument to skip the first line. * lisp/org-src.el (org-src--coordinates): Fix coordinates for inline LaTeX fragments. (org-src--contents-for-write-back): Do not indent first line for LaTeX fragments. (org-src--edit-element): Compute block-indentation according to parent for LaTeX fragments. Skip first line when removing common indentation for LaTeX fragments. --- lisp/org-macs.el | 9 ++--- lisp/org-src.el | 18 ++ 2 files changed, 20 insertions(+), 7 deletions(-) diff --git a/lisp/org-macs.el b/lisp/org-macs.el index bf1340b0a..1ef89a04d 100644 --- a/lisp/org-macs.el +++ b/lisp/org-macs.el @@ -326,17 +326,19 @@ it for output." ;;; Indentation -(defun org-do-remove-indentation ( n) +(defun org-do-remove-indentation ( n skip-fl) "Remove the maximum common indentation from the buffer. When optional argument N is a positive integer, remove exactly -that much characters from indentation, if possible. Return nil -if it fails." +that much characters from indentation, if possible. When +optional argument SKIP-FL is non-nil, skip the first +line. Return nil if it fails." (catch :exit (goto-char (point-min)) ;; Find maximum common indentation, if not specified. (let ((n (or n (let ((min-ind (point-max))) (save-excursion + (when skip-fl (forward-line)) (while (re-search-forward "^[ \t]*\\S-" nil t) (let ((ind (current-indentation))) (if (zerop ind) (throw :exit nil) @@ -344,6 +346,7 @@ if it fails." min-ind (if (zerop n) (throw :exit nil) ;; Remove exactly N indentation, but give up if not possible. +(when skip-fl (forward-line)) (while (not (eobp)) (let ((ind (progn (skip-chars-forward " \t") (current-column (cond ((eolp) (delete-region (line-beginning-position) (point))) diff --git a/lisp/org-src.el b/lisp/org-src.el index 3b25fad60..d78f46186 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -327,7 +327,8 @@ a cons cell (LINE . COLUMN) or symbol `end'. See also (if (>= pos end) 'end (org-with-wide-buffer (goto-char (max beg pos)) - (cons (count-lines beg (line-beginning-position)) + (cons (count-lines (save-excursion (goto-char beg) (line-beginning-position)) +(line-beginning-position)) ;; Column is relative to the end of line to avoid problems of ;; comma escaping or colons appended in front of the line. (- (point) (min end (line-end-position))) @@ -445,6 +446,7 @@ Assume point is in the corresponding edit buffer." org-src--content-indentation 0 (use-tabs? (and (> org-src--tab-width 0) t)) +(preserve-fl (eq org-src--source-type 'latex-fragment)) (source-tab-width org-src--tab-width) (contents (org-with-wide-buffer (let ((eol (line-end-position))) @@ -466,7 +468,8 @@ Assume point is in the corresponding edit buffer." ;; Add INDENTATION-OFFSET to every line in buffer, ;; unless indentation is meant to be preserved. (when (> indentation-offset 0) - (while (not (eobp)) + (when preserve-fl (forward-line)) +(while (not (eobp)) (skip-chars-forward " \t") (when (or (not (eolp)) ; not a blank line (and (eq (point) (marker-position marker)) ; current line @@ -518,7 +521,13 @@ Leave point in edit buffer." (source-tab-width (if indent-tabs-mode tab-width 0)) (type (org-element-type datum)) (block-ind (org-with-point-at (org-element-property :begin datum) - (current-indentation))) + (cond + ((save-excursion (skip-chars-backward " \t") (bolp)) + (current-indentation)) + ((org-element-property :parent datum) +(org--get-expected-indentation + (org-element-property :parent datum) nil)) + (t (current-indenta
Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: [kisara.moe] Re: Bug: async latex export fails due to post-process lambda [9.4.4 (release_9.4.4-188-ga8df76 @ /home/mohkale/.con
Hi, Mohsin Kaleem writes: Hi, just following up. This is still an issue. I can confirm this. I've run into the same issue and fix. Are you using native compilation ? I think this must be the cause, though no one else could reproduce. If I byte compile the function instead, things work. Regards, -- Sébastien Miquel
[PATCH] Re: Bug: org-edit-special indents inline latex [9.5 (nil @ /home/david/.emacs.d/.local/straight/build-27.2/org-mode/)]
Hi, Ihor Radchenko writes: Dávid Jakab writes: When using org-edit-special to edit inline latex, i.e., equations between \( and \), in an org-mode buffer, a number of spaces may get inserted before \( after the latex editing minibuffer is closed. The attached patch fixes this as well as a couple other issues with special editing of latex fragments : + the coordinates computation was wrong, so point position inside fragment isn't preserved when calling ~org-edit-special~ from an inline fragment. + common leading indentation wasn't getting trimmed when editing a multiline fragment inside an org list such as $$abc def$$ Thanks for reporting and confirming. Regards, -- Sébastien Miquel >From 5c3254d42e3d359021d41dae9a0549244e6fddff Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Mon, 30 Aug 2021 23:18:41 +0200 Subject: [PATCH] org-src.el: Fix special editing of LaTeX fragments * lisp/org-macs.el (org-do-remove-indentation): Add optional argument to skip the first line. * lisp/org-src.el (org-src--coordinates): Fix coordinates for inline LaTeX fragments. (org-src--contents-for-write-back): Do not indent first line for LaTeX fragments. (org-src--edit-element): Compute block-indentation according to parent for LaTeX fragments. Skip first line when removing common indentation for LaTeX fragments. --- lisp/org-macs.el | 9 ++--- lisp/org-src.el | 18 ++ 2 files changed, 20 insertions(+), 7 deletions(-) diff --git a/lisp/org-macs.el b/lisp/org-macs.el index 77458db96..5c90c92f6 100644 --- a/lisp/org-macs.el +++ b/lisp/org-macs.el @@ -326,17 +326,19 @@ it for output." ;;; Indentation -(defun org-do-remove-indentation ( n) +(defun org-do-remove-indentation ( n skip-fl) "Remove the maximum common indentation from the buffer. When optional argument N is a positive integer, remove exactly -that much characters from indentation, if possible. Return nil -if it fails." +that much characters from indentation, if possible. When +optional argument SKIP-FL is non-nil, skip the first +line. Return nil if it fails." (catch :exit (goto-char (point-min)) ;; Find maximum common indentation, if not specified. (let ((n (or n (let ((min-ind (point-max))) (save-excursion + (when skip-fl (forward-line)) (while (re-search-forward "^[ \t]*\\S-" nil t) (let ((ind (current-indentation))) (if (zerop ind) (throw :exit nil) @@ -344,6 +346,7 @@ if it fails." min-ind (if (zerop n) (throw :exit nil) ;; Remove exactly N indentation, but give up if not possible. +(when skip-fl (forward-line)) (while (not (eobp)) (let ((ind (progn (skip-chars-forward " \t") (current-column (cond ((eolp) (delete-region (line-beginning-position) (point))) diff --git a/lisp/org-src.el b/lisp/org-src.el index 4698c6dd2..2e72b1755 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -324,7 +324,8 @@ a cons cell (LINE . COLUMN) or symbol `end'. See also (if (>= pos end) 'end (org-with-wide-buffer (goto-char (max beg pos)) - (cons (count-lines beg (line-beginning-position)) + (cons (count-lines (save-excursion (goto-char beg) (line-beginning-position)) +(line-beginning-position)) ;; Column is relative to the end of line to avoid problems of ;; comma escaping or colons appended in front of the line. (- (point) (min end (line-end-position))) @@ -442,6 +443,7 @@ Assume point is in the corresponding edit buffer." org-src--content-indentation 0 (use-tabs? (and (> org-src--tab-width 0) t)) +(preserve-fl (eq org-src--source-type 'latex-fragment)) (source-tab-width org-src--tab-width) (contents (org-with-wide-buffer (buffer-string))) (write-back org-src--allow-write-back)) @@ -456,7 +458,8 @@ Assume point is in the corresponding edit buffer." ;; Add INDENTATION-OFFSET to every line in buffer, ;; unless indentation is meant to be preserved. (when (> indentation-offset 0) - (while (not (eobp)) + (when preserve-fl (forward-line)) +(while (not (eobp)) (skip-chars-forward " \t") (let ((i (current-column))) (delete-region (line-beginning-position) (point)) @@ -504,7 +507,13 @@ Leave point in edit buffer." (source-tab-width (if indent-tabs-mode tab-width 0)) (type (org-element-type datum)) (block-ind (org-with-point-at (org-element-property :begin datum) - (current-indentation))) + (cond + ((save-excursion (skip-chars-backward " \t") (bolp)) + (current-indentation)) + ((org-element-property :parent datum) +(org--get-expected-indentation + (org-element-property :parent datum) nil)) +
Re: Bug: [PATCH] Can't set background color of latex fragment
Sébastien Miquel writes: Here's a patch that fixes this bug by calling `dvipng' with the `-bg Transparent' argument only when no background color is set. Setting X-Woof-Bug and X-Woof-Patch, as this doesn't show on https://updates.orgmode.org/ -- Sébastien Miquel
Re: [BUG] Async pdf export broken with native-comp
Hi, Timothy writes: > FWIW I use native-comp (with Doom + my config) and async PDF export > works. Would you mind checking that ~org-latex-export-to-pdf~ is native compiled, using =describe-function= ? I've updated to latest emacs master and I'm still hitting this issue, although the steps to reproduce in my original mail are wrong : + with =emacs -q= async export fails, but for a different reason : I get a =wrong argument stringp, nil= error because ~user-init-file~ is nil inside ~org-export-async-start~. + The issue I described occurs when you use an empty init.el file and start =emacs=. Perhaps you need to make sure that ~org-latex-export-to-pdf~ is native compiled. Regards, -- Sébastien Miquel
[BUG] Async pdf export broken with native-comp
Hi, The async pdf export functionality appears to be broken with latest org and a recent emacs version compiled with native-comp enabled (I have not tested without native-comp). To reproduce: - use `emacs -q` and an empty init.el file (your init file gets picked up by the async emacs instance) - (setq org-export-async-debug t) - find any org file and hit =C-c C-e C-a C-l C-p= to export as pdf file. The async process will exit abnormaly. The issue stems from this line in `org-export-to-file` : (ignore-errors (funcall ',post-process ,file)) In `org-latex-export-to-pdf`, this `post-process` is set to : (lambda (file) (org-latex-compile file)) I think native-comp compiles this lambda, which messes things up. As a fix, you can quote the lambda in `org-latex-export-to-pdf` : '(lambda (file) (org-latex-compile file)) The same applies to other backends but I don't know if it's the right thing to do. Regards, -- Sébastien Miquel
Re: [PATCH] Do not throw error when parameter of :tangle is not a string
Hi, Jacopo De Simoi writes: in the current master branch, if the parameter :tangle of a src block is not a string, tangling fails by throwing an error when calling `file-name- directory' This patch checks if the parameter is a string before calling `file-name-directory'. This makes construct such as :tangle (when condition-applies "filename") work again (as they did a few versions ago…) Thanks for the patch. It looks good to me (had to run `dos2unix' to apply). To clarify, it fixes `:tangle (when condition-applies "filename")' when the condition doesn't apply, such as `(when nil "filename")'. Regards, -- Sébastien Miquel
Re: Large source block causes org-mode to be unusable
Hi,
Léo Ackermann writes:
@EricSFrada, would you mind sharing your code for your proof sections ?
This functionality is now built-in: headings with an `ignore' tag do not get
exported (their contents do). For very large proof, this seems like the
right
thing to do.
In small to moderate sized blocks, the delay can still be noticeable and
ought
to be fixed. Attached is a patch that seems to resolve this issue. I haven't
noticed any drawbacks so far.
Regards,
--
Sébastien Miquel
>From d843bdc5887a6e50a57e349128ebbe032086dc17 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?=
Date: Sun, 27 Jun 2021 16:24:22 +0200
Subject: [PATCH] WIP : do not refontify special blocks
---
lisp/org.el | 99 ++---
1 file changed, 64 insertions(+), 35 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 1bd9e02eb..9fd3f8514 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5265,22 +5265,32 @@ by a #."
(org-fontify-meta-lines-and-blocks-1 limit)
(error (message "Org mode fontification error in %S at %d"
(current-buffer)
- (line-number-at-pos)
+ (line-number-at-pos
+ nil)
(defun org-fontify-meta-lines-and-blocks-1 (limit)
"Fontify #+ lines and blocks."
- (let ((case-fold-search t))
-(when (re-search-forward
- (rx bol (group (zero-or-more (any " \t")) "#"
- (group (group (or (seq "+" (one-or-more (any "a-zA-Z")) (optional ":"))
- (any " \t")
- eol))
- (optional (group "_" (group (one-or-more (any "a-zA-Z"))
- (zero-or-more (any " \t"))
- (group (group (zero-or-more (not (any " \t\n"
- (zero-or-more (any " \t"))
- (group (zero-or-more any)
- limit t)
+ (let* ((case-fold-search t)
+ (fl-beg (point))
+ (fl-end limit)
+ (fbeg (when (and (> fl-beg (point-min))
+ (get-text-property (1- fl-beg) 'font-lock-multiline-block))
+ (or (previous-single-property-change
+ fl-beg 'font-lock-multiline-block)
+ (point-min)
+(when fbeg (goto-char fbeg))
+(while (and (< (point) limit)
+(re-search-forward
+ (rx bol (group (zero-or-more (any " \t")) "#"
+ (group (group (or (seq "+" (one-or-more (any "a-zA-Z")) (optional ":"))
+ (any " \t")
+ eol))
+ (optional (group "_" (group (one-or-more (any "a-zA-Z"))
+ (zero-or-more (any " \t"))
+ (group (group (zero-or-more (not (any " \t\n"
+ (zero-or-more (any " \t"))
+ (group (zero-or-more any)
+ limit t))
(let ((beg (match-beginning 0))
(end-of-beginline (match-end 0))
;; Including \n at end of #+begin line will include \n
@@ -5318,7 +5328,7 @@ by a #."
(remove-text-properties beg end-of-endline
'(display t invisible t intangible t)))
(add-text-properties
- beg end-of-endline '(font-lock-fontified t font-lock-multiline t))
+ beg end-of-endline '(font-lock-fontified t font-lock-multiline-block t))
(org-remove-flyspell-overlays-in beg bol-after-beginline)
(org-remove-flyspell-overlays-in nl-before-endline end-of-endline)
(cond
@@ -5327,7 +5337,8 @@ by a #."
(add-text-properties bol-after-beginline block-end '(src-block t)))
(quoting
(add-text-properties
- bol-after-beginline beg-of-endline
+ (max bol-after-beginline (or fl-beg bol-after-beginline))
+ (min beg-of-endline (or fl-end beg-of-endline))
(list 'face
(list :inherit
(let ((face-name
@@ -5426,26 +5437,41 @@ by a #."
(add-text-properties closing-start end '(invisible t)))
t)
-(defun org-fontify-extend-region (beg end _old-len)
- (let ((begin-re "\\(\\[\\|\\(#\\+begin_\\|begin{\\)\\S-+\\)")
- (end-re "\\(\\]\\|\\(#\\+end_\\|end{\\)\\S-+\\)")
- (extend
- (lambda (r1 r2 dir)
- (let ((re (replace-regexp-in-string
- "\\(begin\\|end\\)" r1
- (replace-regexp-in-string
- "[][]" r2
- (match-string-no-properties 0)
- (re-search-forward (regexp-quote re) nil t dir)
-(save-match-data
- (save-excursion
- (goto-char beg)
- (back-to-indentation)
- (cond ((looking-at end-re)
- (cons (or (funcall extend "begin" "[" -1) beg) end))
- ((looking-at begin-re)
- (cons beg (or (funcall extend "end" "]" 1) end)))
- (t (cons beg end)))
+(defun org-fontify-extend-region (bego endo _old-len)
+ (let* ((beg bego)
Re: [PATCH] extra space at the end of lines in source
Greg Minshall writes: thanks. my trivial test shows this works*except* in the particular case where, when closing the Org Src buffer, `point` is on an empty line. in this case, that one empty line is given extra spaces. Yes, I was aware of this, but didn't think we could do better in this case. I've thought about it some more, and came up with a solution. Here's a new patch that's smarter about indenting the current line, and resolves this remaining issue. Regards, -- Sébastien Miquel >From 8c31e6b732a45c0ddbbf0a0db7a2cb4ef3af0414 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Wed, 23 Jun 2021 15:25:58 +0200 Subject: [PATCH] org-src.el: Do not indent blank lines, except current one * lisp/org-src.el (org-src--contents-for-write-back): Do not indent blank lines, except for the current line maybe. (org-src--preserve-blank-line): New variable, whether to preserve indentation of the current blank line. (org-src--edit-element): Set `org-src--preserve-blank-line'. * lisp/org.el (org-indent-line): When tab acts natively, do some preindentation, which signals `org-src--edit-element' to preserve the indentation of current blank line. Removing all the whitespace was the original behaviour for all blank lines, before `857ae366b3`. --- lisp/org-src.el | 34 +++--- lisp/org.el | 15 +++ 2 files changed, 42 insertions(+), 7 deletions(-) diff --git a/lisp/org-src.el b/lisp/org-src.el index 79f002e56..c6311adbb 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -299,6 +299,9 @@ is 0.") "File name associated to Org source buffer, or nil.") (put 'org-src-source-file-name 'permanent-local t) +(defvar-local org-src--preserve-blank-line nil) +(put 'org-src--preserve-blank-line 'permanent-local t) + (defun org-src--construct-edit-buffer-name (org-buffer-name lang) "Construct the buffer name for a source editing buffer." (concat "*Org Src " org-buffer-name "[ " lang " ]*")) @@ -443,14 +446,21 @@ Assume point is in the corresponding edit buffer." 0 (use-tabs? (and (> org-src--tab-width 0) t)) (source-tab-width org-src--tab-width) - (contents (org-with-wide-buffer (buffer-string))) - (write-back org-src--allow-write-back)) + (contents (org-with-wide-buffer + (let ((eol (line-end-position))) + (list (buffer-substring (point-min) eol) + (buffer-substring eol (point-max)) + (write-back org-src--allow-write-back) +(preserve-blank-line org-src--preserve-blank-line) +marker) (with-current-buffer write-back-buf ;; Reproduce indentation parameters from source buffer. (setq indent-tabs-mode use-tabs?) (when (> source-tab-width 0) (setq tab-width source-tab-width)) ;; Apply WRITE-BACK function on edit buffer contents. - (insert (org-no-properties contents)) + (insert (org-no-properties (car contents))) + (setq marker (point-marker)) + (insert (org-no-properties (car (cdr contents (goto-char (point-min)) (when (functionp write-back) (save-excursion (funcall write-back))) ;; Add INDENTATION-OFFSET to every line in buffer, @@ -458,10 +468,14 @@ Assume point is in the corresponding edit buffer." (when (> indentation-offset 0) (while (not (eobp)) (skip-chars-forward " \t") - (let ((i (current-column))) - (delete-region (line-beginning-position) (point)) - (indent-to (+ i indentation-offset))) - (forward-line)) + (when (or (not (eolp)) ; not a blank line +(and (eq (point) (marker-position marker)) ; current line + preserve-blank-line)) + (let ((i (current-column))) + (delete-region (line-beginning-position) (point)) + (indent-to (+ i indentation-offset + (forward-line))) + (set-marker marker nil (defun org-src--edit-element (datum name initialize write-back contents remote) @@ -506,6 +520,11 @@ Leave point in edit buffer." (block-ind (org-with-point-at (org-element-property :begin datum) (current-indentation))) (content-ind org-edit-src-content-indentation) + (blank-line (save-excursion (beginning-of-line) + (looking-at-p "^[[:space:]]*$"))) + (empty-line (and blank-line (looking-at-p "^$"))) + (preserve-blank-line (or (and blank-line (not empty-line)) + (and empty-line (= (+ block-ind content-ind) 0 (preserve-ind (and (memq type '(example-block src-block)) (or (org-element-property :preserve-indent datum) @@ -554,6 +573,7 @@ Leave point in edit buffer." (setq org-src--overlay overlay) (setq org-src--allow-write-back write-back) (setq org-src-sour
Re: [PATCH] extra space at the end of lines in source
Greg Minshall writes: - the next time i open the Org Src buffer, whatever lint-like process is running for that language may complain about extra spaces at the end of a line. (does that mean my experience is different from yours, or at least from your expectation?) If I try your original examples with `emacs -q' I do not get extra whitespace in the org src buffer. Those two spaces in the original org buffer -- that are due to `org-edit-src-content-indentation' -- are removed in the org src buffer. If you do not find it to be the case, then I'm missing something. Anyway, here's a patch that cleans up blank lines, except the current one. It preserves the fix for the original issue. Can you try it out ? Regards, -- Sébastien Miquel >From 405c2be7487c564e72a9f01a940f96dc19ff16ad Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Wed, 23 Jun 2021 15:25:58 +0200 Subject: [PATCH] org-src.el (org-src--contents-for-write-back): Do not indent blank lines * lisp/org-src.el (org-src--contents-for-write-back): Do not indent blank lines, except for the current line. This was the original behaviour for all blank lines, before `857ae366b3`. --- lisp/org-src.el | 23 --- 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/lisp/org-src.el b/lisp/org-src.el index 79f002e56..faacb53e3 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -443,14 +443,20 @@ Assume point is in the corresponding edit buffer." 0 (use-tabs? (and (> org-src--tab-width 0) t)) (source-tab-width org-src--tab-width) - (contents (org-with-wide-buffer (buffer-string))) - (write-back org-src--allow-write-back)) + (contents (org-with-wide-buffer + (let ((eol (progn (end-of-line) (point + (list (buffer-substring (point-min) eol) + (buffer-substring eol (point-max)) + (write-back org-src--allow-write-back) +marker) (with-current-buffer write-back-buf ;; Reproduce indentation parameters from source buffer. (setq indent-tabs-mode use-tabs?) (when (> source-tab-width 0) (setq tab-width source-tab-width)) ;; Apply WRITE-BACK function on edit buffer contents. - (insert (org-no-properties contents)) + (insert (org-no-properties (car contents))) + (setq marker (point-marker)) + (insert (org-no-properties (car (cdr contents (goto-char (point-min)) (when (functionp write-back) (save-excursion (funcall write-back))) ;; Add INDENTATION-OFFSET to every line in buffer, @@ -458,10 +464,13 @@ Assume point is in the corresponding edit buffer." (when (> indentation-offset 0) (while (not (eobp)) (skip-chars-forward " \t") - (let ((i (current-column))) - (delete-region (line-beginning-position) (point)) - (indent-to (+ i indentation-offset))) - (forward-line)) + (when (or (not (eolp)) ; ignore blank lines +(eq (point) (marker-position marker))) + (let ((i (current-column))) + (delete-region (line-beginning-position) (point)) + (indent-to (+ i indentation-offset + (forward-line))) + (set-marker marker nil (defun org-src--edit-element (datum name initialize write-back contents remote) -- 2.32.0
Re: extra space at the end of lines in source
For the record, the original issue is that with `org-src-tab-acts-natively' set to t (which is the new default) you couldn't use tab to indent an empty line, and electric-indent-mode wouldn't work properly. Greg Minshall writes: i don't know what would be involved to keep the fix for the original problem (which i was also seeing), without adding these extra spaces. but, i suspect it would be worth it, if feasible. I think the only way would be to change `org-src--contents-for-write-back' to keep track of where the point was in the edit buffer, and clean up spaces in other lines. Doesn't seem difficult ; maybe you could replace the `buffer-string` call by two calls, to get the part before point and the one after, then work with that. it's long-term emacs behavior to eliminate spaces at the end of lines, at least in programming modes. As for the `org-src--content-indentation' spaces, they are quite peculiar. Note that they are removed when you call =C-c '= and when you tangle (they should, but I haven't tested it), so strictly speaking, they are removed in programming modes. What if your org block itself is indented, do you also expect blank lines to be entirely empty ? As for additional indentation in a blank line, it will indeed never get cleaned up by org, which isn't ideal. But then, spaces at the end of non blank lines don't get cleaned up either (I think) and never were. It's up to the user to remove them, in the appropriate language mode. Despite these arguments, I have no opinion on the matter. Regards, -- Sébastien Miquel
Re: extra space at the end of lines in source
Hi Greg, Greg Minshall writes: hi. i can't date it exactly, but in the last week or so, editing a source buffer (with =C-c '=) adds spaces (to the "tab location") of previously blank lines. See https://lists.gnu.org/archive/html/emacs-orgmode/2021-05/msg00867.html The goal of the change was to fix some (electric) indentation issues when editing a src block directly. As I write in the linked thread, setting `org-src--preserve-indentation' should revert this behaviour. Regards, -- Sébastien Miquel
Re: org-edit-src-exit randomizes / mixes up code in source-buffer on exit
Hi, This has been reported before. There's a patch that fixes this here : https://lists.gnu.org/archive/html/emacs-orgmode/2021-06/msg7.html To fix this bug, you can can either apply this patch, downgrade org, or update emacs to 27. Could anyone with commit access have a look and apply this patch to master ? Regards, -- Sébastien Miquel
Re: Large source block causes org-mode to be unusable
Hi Léo, Léo Ackermann writes: I am working in an org-file of reasonable size (<2000 lines): my first paper written in org-mode. Everything fine (and fast) until I started to add `#+BEGIN_proof / #+END_proof` within my .org to make my .pdf export prettier. This caused the editing of the proofs to be very slow: navigation within the proof is fast but adding/removing any char takes around 4s per char. It seems that the fontify function is responsible for that (see screenshot). As far as I understand, this function tries to fontify the whole block as soon as a single char is modified. In my case, it then tries to fontify a whole proof (~4 pages in my .pdf, with many LaTeX formulas) several times per second... You can try setting org-highlight-latex-and-related to '(latex) instead of '(native). Even with this setting, latex fontification in special blocks is slow. The reason being that the whole block has the `font-lock-multiline' property, hence every char insertion triggers refontification of the whole block. In the function `org-do-latex-and-related', I commented out the second condition of the `cond' form, which makes calls to `face-at-point'. This yields a significant speedup, and was enough to make things bearable in my cases. You can also try to simplify the latex regexp. If you try these, I'd be interested to hear how much of an improvement theymake. Regards, -- Sébastien Miquel
Re: Default entry in org-src-block-faces
Hi, Augusto Stoffel writes: Would it make sense to allow a default entry (t FACE) in `org-src-block-faces', to be applied to all src blocks without a more specific entry in that alist? There seems to be no other way to specify a face to be applied to all src blocks, and only src blocks. Makes sense to me. I also wonder if there's any reason for the `org-block' face not to apply to "greater" blocks. -- Sébastien Miquel
Re: An org-latex face
Sébastien Miquel writes: There's already an `org-latex-and-relatex` regexp I meant the `org-latex-and-related` face. -- Sébastien Miquel
Re: [PATCH] source blocks mangled when edited
Michael Gauland writes: This is all the*trace-output* buffer shows: == 1 -> (replace-buffer-contents #) 1 <- replace-buffer-contents: nil Indeed, the `replace-buffer-contents` call is failing. I've been able to reproduce with earlier versions of emacs 26.1. With later versions of emacs 26, the problem goes away. It seems earlier versions of `replace-buffer-contents` are not quite reliable. It was patched prior to 27.1 and the new documentation string makes some guarantees of correctness, so let's just change the minimal version to 27.1. Thank you for the report. Regards, -- Sébastien Miquel X-Woof-Bug: confirmed >From 8ebdbc5eca92de4429d3994a3663d8aa3b9877fe Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Tue, 1 Jun 2021 08:56:48 +0200 Subject: [PATCH] org-src.el: Use `replace-buffer-contents' only for emacs >= 27 * lisp/org-src.el: Use `replace-buffer-contents' only for emacs >= 27. It was introduced in emacs 26.1, but earlier versions made no guarantees of correctness. --- lisp/org-src.el | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/lisp/org-src.el b/lisp/org-src.el index 79f002e56..4698c6dd2 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -1199,12 +1199,12 @@ Throw an error if there is no such buffer." ;; insert new contents. (delete-overlay overlay) (let ((expecting-bol (bolp))) - (if (version< emacs-version "26.1") + (if (version< emacs-version "27.1") (progn (delete-region beg end) (insert (with-current-buffer write-back-buf (buffer-string (save-restriction (narrow-to-region beg end) - (replace-buffer-contents write-back-buf) + (replace-buffer-contents write-back-buf 0.1 nil) (goto-char (point-max (when (and expecting-bol (not (bolp))) (insert "\n"))) (kill-buffer write-back-buf) @@ -1246,13 +1246,13 @@ Throw an error if there is no such buffer." (undo-boundary) (goto-char beg) (let ((expecting-bol (bolp))) - (if (version< emacs-version "26.1") + (if (version< emacs-version "27.1") (progn (delete-region beg end) (insert (with-current-buffer write-back-buf (buffer-string (save-restriction (narrow-to-region beg end) - (replace-buffer-contents write-back-buf) + (replace-buffer-contents write-back-buf 0.1 nil) (goto-char (point-max (when (and expecting-bol (not (bolp))) (insert "\n") (when write-back-buf (kill-buffer write-back-buf)) -- 2.31.1
Re: An org-latex face
Hi Léo, Léo Ackermann writes: When it comes to preview inline LaTeX fragments within org-mode, the org package applies the `org-block` face. It would be nice to *treat inline latex block specially*, to make integration of the those preview-block easier when surrounded by plaintext. This feature would allow to have a theme that highlight blocks (source code, examples) without the background artifact you can see in attachment when previewing latex fragments. There's already an `org-latex-and-relatex` regexp, that will be used if you set `org-highlight-latex-and-related` to `'(latex)` instead of `'(native)`. The org-block face won't be applied anymore. Regards, -- Sébastien Miquel
