Re: [BUG] [PATCH] org-babel-execute-buffer: Prevent executing non-code blocks [9.6.20 ( @ /home/cassou/.emacs.d/lib/org/lisp/)]
On 16.03.2024 12:48, Ihor Radchenko wrote: Yes. You can add #+property: header-args:text :eval no on top of your Org file or add (setq org-babel-default-header-args:text '((:eval . "no"))) to your config. Is it possible to make org-lint recognize those settings? I have the kludge (defun org-babel-execute:text (_body _params) "NO-OP to silence warnings." nil) in my config to silence "Unknown source block language" warnings. Regards -- Gerard
Re: Things got very slow: profiler output
On 14.03.2024 02:17, William Denton wrote: On Wednesday, March 13th, 2024 at 19:19, Bruno Cardoso wrote: For me this improved the situation a bit, but I still get significant slow-downs as before. I don't know if it is related, but if I set a property (C-c C-x p) in a new heading with no drawers, I'm unable to unfold the newly created drawer (TAB over it does nothing), although I am able to fold/unfold other already existent drawers as expected. I see this too and my work-around is calling org-fold-show-all to read the newly created property drawer. I don't have that problem, if I understand your description right, but like you Ihor's tweak didn't get things back to normal for me. I'm now using Emacs from the development tree and its Org (which doesn't yet have commit 5d186b499dde97f5 from 25 February) and it's back to normal for now. I did not notice any of the slow-downs and the output of the cpu profiler looks normal to me. Could it be something our systems or configurations have in common, Bruno? My Org configuration is here, if you want to compare: https://github.com/wdenton/.emacs.d/blob/master/init.org#org I am running GNU Emacs 30.0.50 (build 15, x86_64-apple-darwin20.6.0, NS appkit-2202.70 Version 11.7.1 (Build 20G918)) of 2024-03-14 with a yesterday's Org main. I am using the default theme (light background) and do not do any font tweaking. Thanks for looking at this problem, Ihor. If there's anything else to try, I'll try it. Regards -- Gerard
[PATCH] org-contrib/org-collector.org: fix example link and instructions
Hi, I noticed that the link https://orgmode.org/worg/sources/org-contrib/org-collector-example.org is broken. Furthermore, I think that the usage instructions for Emacs-28.1 and later are outdated. This patch proposes fixes. Regards -- Gerard 0001-org-contrib-org-collector.org-fix-example-link-and-i.patch Description: Binary data
[PATCH] lisp/oc-basic.el: add missing function declarations
Hi, the attached patch adds two missing function declarations to oc-basic.el Regards -- Gerard 0001-lisp-oc-basic.el-add-missing-function-declarations.patch Description: Binary data
Re: How to get in-buffer setting from Elisp code
On 10.03.2024 12:39, Sébastien Gendre wrote:
Hi,
Thank you for your reply.
I talk about the Org-mode In-Buffer settings:
https://orgmode.org/manual/In_002dbuffer-Settings.html
Try for instance: (org-collect-keywords '("TITLE"))
See:
https://emacs.stackexchange.com/questions/21459/programmatically-read-and-set-buffer-wide-org-mode-property
Regards -- Gerard
Re: [PATCH] org-babel-demarcate-block: split using element API
On 04.03.2024 11:12, Ihor Radchenko wrote: What about after https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5f5db3d35 ? This fixes the bug. I resubmit my patch (attached) without any caveats in the commit message. Regards -- Gerard 0001-org-babel-demarcate-block-split-using-element-API.patch Description: Binary data
Re: [PATCH] org-babel-demarcate-block: split using element API
On 03.03.2024 14:08, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: I have reduced my version of `org-babel-demarcate-block' to a minimal function to locate the bug stemming from edit-prep signaling an user-error or not. In case edit-prep signals an user-error the call chain `org-indent-block', `org-indent-region', `org-element-at-point' triggers an infinite list of warnings (major mode is Python when run on the test block). Have you tried the latest main? Yes (just tried again), the minimal function still triggers the "infinite" list of warnings "Warning (org-element): ‘org-element-at-point’ cannot be used in non-Org buffer # (python-mode)" It is coming from the last org-indent-block call even though the message just before tells that the mode is derived from org-mode. Your changes of last thursday helped me to narrow the problem down to this call. Regards -- Gerard
Re: [PATCH] org-babel-demarcate-block: split using element API
On 29.02.2024 12:56, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: That includes `org-babel-demarcate-block' splitting with the patch. I do not understand why it works and why I never see the user-error re-signalled by `org-babel-edit-prep:sql' (even as demoted message). [...] I have reduced my version of `org-babel-demarcate-block' to a minimal function to locate the bug stemming from edit-prep signaling an user-error or not. In case edit-prep signals an user-error the call chain `org-indent-block', `org-indent-region', `org-element-at-point' triggers an infinite list of warnings (major mode is Python when run on the test block). #+begin_src emacs-lisp -n :results silent (defun oeap-test () "Test `org-element-at-point': call with point at block." (interactive) (let* ((info (org-babel-get-src-block-info 'noeval)) (start (org-babel-where-is-src-block-head)) (body (and start (match-string 5 (if (and info start) (let* ((copy (org-element-copy (org-element-at-point))) (before (org-element-begin copy)) (beyond (org-element-end copy))) (org-element-put-property copy :value body) (delete-region before beyond) (insert (org-element-interpret-data copy)) (org-babel-previous-src-block 1) (message "Mode derived from: %S" (derived-mode-p 'org-mode)) ;; Triggers list of warnings and condition-case is no solution: (org-indent-block) #+end_src Working edit-prep: #+begin_src emacs-lisp -n :results silent (defun harm-full-edit-prep (_info) (user-error "Harm-FULL edit-prep")) (defun org-babel-edit-prep:python (info) (condition-case nil (harm-full-edit-prep info) (t nil))) (message "Working edit-prep:python") #+end_src Failing edit-prep: #+begin_src emacs-lisp -n :results silent (defun harm-full-edit-prep (_info) (user-error "Harm-FULL edit-prep")) (defun org-babel-edit-prep:python (info) (harm-full-edit-prep info)) (message "Failing edit-prep:python") #+end_src Test block: #+begin_src python -i -n :results silent 11 22 #+end_src I do not like to put extra constraints on edit-prep functions. Maybe, it is better to cancel the patch. Regards -- Gerard
Re: [PATCH] org-babel-demarcate-block: split using element API
On 28.02.2024 12:54, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: You may wrap `org-indent-block' into `condition-case' to catch user-errors. The caveat is not a real constraint, since Org has limited support for source block editing in an Org mode buffer when an `org-babel-edit-prep:' function signals an user-error. I show that in the attached no-user-errors-in-edit-prep.org. I studied the existing Org handling of various errors related to src edit buffers and it seems that we tend to ignore them in a number of scenarios. In particular, when major mode fails to load for any reason, Org mode does not even throw an error, but simply displays a warning. So, I think that we can similarly ignore errors in edit-prep function, demoting them to messages. (In addition, it does not look like electric-indent-mode triggered in your example file by pressing handles errors gracefully either - yet another reason not to throw errors in `org-indent-*' functions) Does it make sense? Your reply helped me to read the Org Babel code from a different view point. I re-discovered that `org-babel-edit-prep:sql' handles all issues gracefully while trying the block below: #+begin_src sql :engine wrong a b #+end_src That includes `org-babel-demarcate-block' splitting with the patch. I do not understand why it works and why I never see the user-error re-signalled by `org-babel-edit-prep:sql' (even as demoted message). After writing `org-babel-edit-prep:python' like: #+begin_src emacs-lisp -n :results silent (defun harm-full-edit-prep (_info) (user-error "Harm-FULL edit-prep")) (defun org-babel-edit-prep:python (info) "Imitate `org-babel-edit-prep:sql'." (condition-case nil (harm-full-edit-prep info) (user-error "Why is this harm-LESS in `org-babel-edit-prep:sql'?"))) #+end_src and trying it on the block below: #+begin_src python -i -n :results silent 11 22 #+end_src I see that this `org-babel-edit-prep:python' handles all issues like `org-babel-edit-prep:sql' (and it does not matter whether `electric-indent-mode' is disabled or enabled). I conclude (contrary to the previous commit message in the patch): In case functions called by an `org-babel-edit-prep:' function raise an user-error, this `org-babel-edit-prep:' function should re-signal the user-error like `org-babel-edit-prep:sql' does. Attached you'll find the patch with an updated commit message. Regards -- Gerard 0001-org-babel-demarcate-block-split-using-element-API.patch Description: Binary data
Re: [PATCH] org-babel-demarcate-block: split using element API
On 25.02.2024 13:21, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: I added the caveat: This patch is incompatible with `org-babel-edit-prep:' functions that signal `user-error's. to the commit message and cleaned it up a bit. You may wrap `org-indent-block' into `condition-case' to catch user-errors. Sorry, I did attach an old version of no-user-errors-in-edit-prep.org. Corrected. Regards -- Gerard no-user-errors-in-edit-prep.org Description: Binary data
Re: [PATCH] org-babel-demarcate-block: split using element API
On 25.02.2024 13:21, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: I added the caveat: This patch is incompatible with `org-babel-edit-prep:' functions that signal `user-error's. to the commit message and cleaned it up a bit. You may wrap `org-indent-block' into `condition-case' to catch user-errors. The caveat is not a real constraint, since Org has limited support for source block editing in an Org mode buffer when an `org-babel-edit-prep:' function signals an user-error. I show that in the attached no-user-errors-in-edit-prep.org. I also attach condition-case.diff that I use to try to argue that condition-case never gets into its error-handler (I am running the code with the condition-case now), because I never see the signal of ~(user-error "Error in `org-babel-edit-prep:'?")~ (I needed to read the condition-case documentation, because this is the first time I am trying to use it). #+begin_src emacs-lisp -n :results silent ;; Fails with org-babel-demarcate-block in patch. (defun edit-prep-user-error (_info) (user-error "Signaling user-errors is harmfull")) (defun org-babel-edit-prep:python (info) (edit-prep-user-error info)) (message "Harm-FULL edit-prep:python") #+end_src #+begin_src emacs-lisp -n :results silent ;; Works with org-babel-demarcate-block in patch. (defun edit-prep-message (_info) (message "Displaying messages is harmless")) (defun org-babel-edit-prep:python (info) (edit-prep-message info)) (message "Harm-LESS edit-prep:python") #+end_src ~org-babel-demarcate-blocks~ works with "Harm-LESS edit-prep:python" but fails with "Harm-FULL edit-prep:python" and it leaves the Org mode buffer in a state similar to shown in no-user-errors-in-edit-prep.org (I have to pass through org-edit-src-code to be able to edit the block in the Org mode buffer). But I only can do that after interrupting (C-g C-g) an infinite stream of warnings "Warning (org-element): ‘org-element-at-point’ cannot be used in non-Org buffer # (python-mode)" which should come from the `org-element-at-point' call indicated by ;; <= HERE? in condition-case.diff. Test block below: #+begin_src python -i -n :results silent 11 22 #+end_src Regards -- Gerard no-user-errors-in-edit-prep.org Description: Binary data condition-case.diff Description: Binary data
Re: [PATCH] org-babel-demarcate-block: split using element API
On 23.02.2024 14:43, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: [...] I rewrote my `org-babel-edit-prep:python' to get rid of user-errors but then I bumped on the user-error coming from `org-src--make-source-overlay'. This is strange. `org-src--make-source-overlay' does not use `org-element' API. I cannot see how you are getting such warnings from there. I am using since a few days a clone of the mailed `org-babel-edit-prep:python' function (an irrelevant fix for setting point) and it works without glitches. I have no explanation of what happened. I added the caveat: This patch is incompatible with `org-babel-edit-prep:' functions that signal `user-error's. to the commit message and cleaned it up a bit. I also removed the scaffolding from the tests that checks where mark and point are. The tests pass with make test. Patch attached. Regards -- Gerard 0001-org-babel-demarcate-block-split-using-element-API.patch Description: Binary data
Re: [PATCH] org-babel-demarcate-block: split using element API
On 21.02.2024 19:19, gerard.vermeu...@posteo.net wrote: On 21.02.2024 10:40, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: [...] May you please provide more details? This is different of what I saw before: When splitting python blocks in an org file I got a long list of warnings: Warning (org-element): ‘org-element-at-point’ cannot be used in non-Org buffer # (python-mode) until it stopped by itself. I traced this to user-errors in my own `org-babel-edit-prep:python' which I use to let eglot handle python source blocks. I rewrote my `org-babel-edit-prep:python' to get rid of user-errors but then I bumped on the user-error coming from `org-src--make-source-overlay'. I think that this may be the case for other definitions of `org-babel-edit-prep:LANG' I copy my `org-babel-edit-edit-prep:python' without user-errors below: #+begin_src emacs-lisp -n :results silent (with-eval-after-load 'emacs (defcustom eglot-maybe-ensure-modes '(python-mode) "Modes where maybe `eglot-ensure' should be or has been called. This may be in the case of proper directory local variables or in the case of proper `org-src-mode' buffers.") ;; https://www.reddit.com/r/emacs/comments/w4f4u3 ;; /using_rustic_eglot_and_orgbabel_for_literate/ (defun eglot-org-babel-edit-prep (info) "Try to setup an `org-mode-src' buffer to make `eglot-ensure' succeed. INFO has a form similar to the return value of `org-babel-get-src-block-info'. Try to load the tangled file into the `org-src-mode' buffer as well as to narrow the region to the Org-mode source block code before calling `eglot-ensure'." (when-let ((ok (bound-and-true-p org-src-mode)) (mark (point)) (body (nth 1 info)) (filename (cdr (assq :tangle (nth 2 info) (when (string= filename "no") (message "Org source block has no tangled file") (setq ok nil)) (when ok (setq filename (expand-file-name filename)) (unless (file-readable-p filename) (message "Tangled file %s is not readable" filename) (setq ok nil))) (when ok (with-temp-buffer (insert-file-contents filename 'visit nil nil 'replace) (unless (search-forward body nil 'noerror) (message "Org source block does not occur in tangled file %s" filename) (setq ok nil)) (when (search-forward body nil 'noerror) (message "Org source block occurs twice or more in tangled file %s" filename) (setq ok nil (when ok (goto-char (point-min)) (insert-file-contents filename 'visit nil nil 'replace) (search-forward body) (narrow-to-region (match-beginning 0) (match-end 0)) (goto-char mark) (eglot-ensure)) ;; (message "Buffer %s is no `org-src-mode' buffer" (buffer-name)) )) (defun org-babel-edit-prep:python (info) (eglot-org-babel-edit-prep info))) #+end_src Regards -- Gerard
Re: [PATCH] org-babel-demarcate-block: split using element API
On 21.02.2024 10:40, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: Still failing on my side (when running tests non-interactively from command line). To fix the problem, please use the approach from `test-org-list/indent-item': (transient-mark-mode 1) (push-mark (point) t t) Instead of (set-mark-command nil) Gerard, may I know if you had a chance to look into my comments? I think that I have addressed this particular comment. Not really. In any case, see the attached updated patch with my suggestion incorporated. Indeed, I did not address it. I also tried out your suggestion out this morning and saw that it makes "make test" pass. [...] Secondly, I see (saw) sometimes Org emitting warnings with backtraces starting from my patch. I think the warning may be due either to a mistake on my side or a bug in Org, but I am not sure. May you please provide more details? I fail to reproduce the warnings, but I think that I have seen (rx ... ) type warnings in the Emacs warnings buffer with the patched org-babel-demarcate-block as backtrace entry point. I did not capture those at the time, because I thought I could trigger those warnings easily which is not the case. This is Emacs-30.0.50. I am sorry I cannot give more details. How to proceed? Of course, I agree with your version of the patch although I had started to remove some of the superfluous scaffolding to know where point and mark are. Regards -- Gerard
Re: [PATCH] org-babel-demarcate-block: split using element API
On 19.02.2024 10:46, Ihor Radchenko wrote: Ihor Radchenko writes: gerard.vermeu...@posteo.net writes: I think that I have improved my region marking code by using "" in the temp-text as a start. Then, I only have to find where to set mark, and eventually exchange point and mark. Still failing on my side (when running tests non-interactively from command line). To fix the problem, please use the approach from `test-org-list/indent-item': (transient-mark-mode 1) (push-mark (point) t t) Instead of (set-mark-command nil) Gerard, may I know if you had a chance to look into my comments? I think that I have addressed this particular comment. However, I am confused by your comments concerning this example #+begin_src emacs-lisp '(1 2 3) '(1 2 3) #+end_src since it breaks my patch as well as main in the sense that such examples can generate three blocks with invalid code. I think there is in general no way to protect a user against bad selections for splitting by demarcation. Secondly, I see (saw) sometimes Org emitting warnings with backtraces starting from my patch. I think the warning may be due either to a mistake on my side or a bug in Org, but I am not sure. Regards -- Gerard
Re: [PATCH] ox-latex: Make more variables file local safe
On 10.02.2024 00:04, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: I have a direct use for org-latex-toc-command being a file local safe variable and I looked a bit around for other variables not being file local safe for no good reason IMO (why those not, while similar variables yes). I have attached a patch which makes six variables file local safe. Thanks! I agree about all but org-latex-toc-command. Although, I am not sure if org-latex-toc-command is really safe to set to arbitrary value. You are right, it is not safe, BUT: The attached org file (not really malicious) shows how to create a malicious org file for any file local "safe" string variable in ox-latex when exporting to latex and compiling with the -shell-escape option. Therefore, I attached a patch removing the :safe #'stringp from those variables. malicious.org Description: Binary data 0001-ox-latex-string-variables-are-not-file-local-safe.patch Description: Binary data
[PATCH] ox-latex: Make more variables file local safe
Hi, I have a direct use for org-latex-toc-command being a file local safe variable and I looked a bit around for other variables not being file local safe for no good reason IMO (why those not, while similar variables yes). I have attached a patch which makes six variables file local safe. Regards -- Gerard 0001-ox-latex-Make-more-variables-file-local-safe.patch Description: Binary data
Re: [BUG]: contradictory requirements between resolving links and noweb result block
On 02.02.2024 21:12, Ihor Radchenko wrote:
gerard.vermeu...@posteo.net writes:
I want to have a kind of dynamic RESULTS: noweb block to select what
other block to put in the LaTeX preamble on LaTeX export.
I can get it working, but in this case links to the RESULTS: noweb
block
are not resolved. I found no way to get the links resolved without
breaking Noweb. See my MWE with instructions below:
May you please provide more detailed information about your MWE?
What exactly are the steps? What did you expect to happen? What
happened instead?
I have turned my MWE into two almost identical MWE's (attached,
including a diff), so that LaTeX export output shows the problem.
I start with my expectations and then I explain what contains the
LaTeX output for mwe-noweb-ok.org and mwe-links-ok.org.
* LaTeX export objectives
Noweb should work, meaning that the LaTeX output preamble should
contain (above \author) the line:
#+begin_src latex
% Should go to the LaTeX preamble above \author{}.
#+end_src
Resolving links should work, meaning that the LaTeX output should
contain (below \tableofcontents) the line
#+begin_src latex
Listing \ref{noop}, \ref{make-noweb}, and \ref{make-noweb-result}.
#+end_src
where all links have user labels.
* mwe-noweb-ok
Export of mwe-noweb-ok.org to LaTeX shows that noweb works
Noweb works, because the preamble contains:
#+begin_src latex
% Should go to the LaTeX preamble above \author{}.
#+end_src
Resolving the last link fails, because it has an org-id
#+begin_src latex
Listing \ref{noop}, \ref{make-noweb}, and \ref{orgd105392}.
#+end_src
while the caption of the linked listing has a user label.
* mwe-links-ok
Noweb fails, because the LaTeX output preamble does contain
#+begin_src latex
\usepackage{hyperref}
\author{Gerard Vermeulen}
#+end_src
without the LaTeX comment.
Resolving links works, because the LaTeX output contains
#+begin_src latex
Listing \ref{noop}, \ref{make-noweb}, and \ref{make-noweb-result}.
#+end_src
* Problem
I can find no configuration where noweb and resolving the link
to the noweb block works.
Regards -- Gerard
mwe-noweb-ok.org
Description: Binary data
mwe-links-ok.org
Description: Binary data
mwe.diff
Description: Binary data
[BUG]: contradictory requirements between resolving links and noweb result block
Hi,
I want to have a kind of dynamic RESULTS: noweb block to select what
other block to put in the LaTeX preamble on LaTeX export.
I can get it working, but in this case links to the RESULTS: noweb block
are not resolved. I found no way to get the links resolved without
breaking Noweb. See my MWE with instructions below:
--- begin Org file ---
# -*- org-latex-prefer-user-labels: t -*- for easier understanding
Listing [[noop]], [[make-noweb]], and [[make-noweb-result]].
#+caption: NOOP
#+name: noop
#+begin_src latex :exports code
% I want to be in the LaTeX preamble above \author{}.
#+end_src
BUG: contradictory requirements for listing [[make-noweb-result]]:
1. Noweb works only in case [[make-noweb]] wraps [[make-noweb-result]]
with
*:exports both*.
2. Resolving links works only in case [[make-noweb]] wraps
[[make-noweb-result]] with *:exports code*.
#+caption: Change after 1st :exports "both" to "code" and vice versa.
#+caption: Execute this block after changing, but before LaTeX export.
#+header: :wrap "src latex -n :exports both :noweb yes :results raw"
#+name: make-noweb
#+begin_src emacs-lisp :exports both :eval no-export
"#+latex_header: <>"
#+end_src
#+caption: I try to put listing [[noop]] body in the LaTeX preamble.
#+name: make-noweb-result
#+RESULTS: make-noweb
#+begin_src latex -n :exports both :noweb yes :results raw
,#+latex_header: <>
#+end_src
--- end Org file ---
I realize that this way of doing is contrived.
What I like about it, is that the [[make-noweb-results]] is directly
visible. I can probably also modify `org-latex-packages-alist' but
that is less visible.
Regards -- Gerard
[PATCH] lisp/ox-latex.el: make org-latex-prefer-user-labels safe file local
Hi, I think that it is inconsistent that `org-latex-reference-command' is a safe file local variable while `org-latex-prefer-user-labels' is not (it makes no sense to set the first at file scope, while the second is nil at global scope). Furthermore, `org-html-prefer-user-labels' is also a safe file local variable. The attached patch fixes this. Regards -- Gerard 0001-lisp-ox-latex.el-make-org-latex-prefer-user-labels-s.patch Description: Binary data
[PATCH] lisp/ox-latex.el: improve org-latex-toc-command docstring
Hi,
I have read the docstring of `org-latex-toc-command' too literally
to discover that specifying anything else than "toc:nil" works.
The attached patch contains a proposal for improvement.
Below there is a not so small mwe.
--- begin mwe ---
#+title: Table of Contents Test
#+latex_class: article
#+options: author:nil date:nil toc:1
#+latex_header: \usepackage{listings}
#+latex_header: \usepackage{minted}
* Test ~toc:~ and ~org-latex-toc-command~
Anything else than ~toc:nil~ in ~#+options:~ above exports the TOC.
#+caption: Execute this block before exporting to a LaTeX buffer or
file.
#+begin_src emacs-lisp :results silent
(when (require 'ox-latex nil 'noerror)
(setq-local org-latex-src-block-backend 'listings)
(setq-local org-latex-toc-command
(cond
((eq org-latex-src-block-backend 'verbatim)
"\\tableofcontents\n\\vspace{10pt}\n")
((eq org-latex-src-block-backend 'listings)
"\\tableofcontents\n\\lstlistoflistings\n\\vspace{10pt}\n")
((memq org-latex-src-block-backend '(minted engraved))
"\\tableofcontents\n\\listoflistings\n\\vspace{10pt}\n"
#+end_src
--- end mwe ---
Regards -- Gerard
0001-lisp-ox-latex.el-improve-org-latex-toc-command-docst.patch
Description: Binary data
[PATCH] lisp/org-src.el: complete `org-src-preserve-indentation' docstring
Hi, I have found by trial and error that `org-indent-block' honors `org-preserve-indentation' which is missing from its docstring. The attached patch contains a proposal to add this fact to the docstring. Regards -- Gerard 0001-lisp-org-src.el-complete-org-src-preserve-indentatio.patch Description: Binary data
Re: [BUG] ox-latex produces broken references to src code listings without caption (was: [BUG] org-lint tells to move #+name to wrong place in results block)
On 25.01.2024 13:41, Ihor Radchenko wrote:
gerard.vermeu...@posteo.net writes:
I have found that CAPTION keywords in the "name-result-example" in
the
manual are essential to produce correct links.
It should not be essential. What you demonstrated is two bugs in Org
mode.
In case the relevant blocks have e.g. ":exports both", Org handles
this, but:
1. HTML export requires captions to produce links with unequivocal
"link texts" which are numbers in the HTML output.
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=ea529007d
I confirm that it is fixed.
2. LaTeX export requires captions to produce captions with labels like
=\caption{\label{path}desc}=.
`org-latex-link' assumes that it is safe to use
\ref{} in order to refer to an existing src
block.
However, it is not true.
`org-latex-src-block--engraved', `org-latex-src-block--minted',
and `org-latex-src-block--listings' only produce a label when src block
has a caption.
We should generally not need to put a caption in order to refer to a
source block listing. At least, it does not look like we need it from
https://tex.stackexchange.com/questions/438260/referencing-without-captions-appearing-but-keeping-numbering
Thoughts? Ideas?
I do not see how to put the LaTeX hypertarget inside listings where it
is
needed, because those listings are not floating.
I looked at `org-latex-src-block--verbatim' that uses the LaTeX
captionof macro, by exporting
--- begin narrow lines below ---
#+caption: caption or comment
#+name: name
#+begin_src emacs-lisp
(+ 1 2)
#+end_src
Link \ref{name}.
--- end narrow lines above
But, I cannot get the captionof macro working after:
exporting the snippet above using `org-latex-src-block--listings'
without caption and adding the captionof macro by hand
(LuaLaTeX does not compile).
Tested on example below:
Produced by listing [[IN]].
#+name: OUT
#+RESULTS: IN
#+begin_src emacs-lisp :exports code
6
#+end_src
#+header: :wrap "src emacs-lisp :exports code"
#+name: IN
#+begin_src emacs-lisp :exports both
6
#+end_src
Listing [[IN]] produces listing [[OUT]].
From inspecting HTML or LaTeX output using this example
for the difference between with and without captions it is
easy to see that only with captions the output is correct.
Regards -- Gerard
Re: [BUG] org-lint tells to move #+name to wrong place in results block
On 22.01.2024 19:59, Ihor Radchenko wrote:
gerard.vermeu...@posteo.net writes:
FR: would it be possible to resolve such links?
What is the purpose? Why not simply leaving the result name same as
the
source block?
I have Python "IN" blocks generating Python "OUT" blocks that may end
up
on different pages after exporting to LaTeX and PDF.
The FR would allow to link always to the correct page.
Patches welcome.
This patch completes my "Make an org-lint warning more helpful" patch.
I have found that CAPTION keywords in the "name-result-example" in the
manual are essential to produce correct links.
In case the relevant blocks have e.g. ":exports both", Org handles
this, but:
1. HTML export requires captions to produce links with unequivocal
"link texts" which are numbers in the HTML output.
2. LaTeX export requires captions to produce captions with labels like
=\caption{\label{path}desc}=.
Tested on example below:
Produced by listing [[IN]].
#+caption: Results block
#+name: OUT
#+RESULTS: IN
#+begin_src emacs-lisp :exports code
6
#+end_src
#+caption: Source block
#+header: :wrap "src emacs-lisp :exports code"
#+name: IN
#+begin_src emacs-lisp :exports both
6
#+end_src
Listing [[IN]] produces listing [[OUT]].
From inspecting HTML or LaTeX output using this example
for the difference between with and without captions it is
easy to see that only with captions the output is correct.
The patch tries to add this information to the manual.
Regards -- Gerard
0001-doc-org-manual-Add-CAPTION-keywords-to-named-results.patch
Description: Binary data
Re: [PATCH] Make an org-lint warning more helpful
On 22.01.2024 19:59, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: FR: would it be possible to resolve such links? What is the purpose? Why not simply leaving the result name same as the source block? I have Python "IN" blocks generating Python "OUT" blocks that may end up on different pages after exporting to LaTeX and PDF. The FR would allow to link always to the correct page. Patches welcome. Another option is :post argument that will add the necessary #+name. I see that my FR is already an Org feature. Attached patch makes the relevant org-lint warning more helpful for fixing user's Org buffers. I still have to think about your ":post argument" option to and #+name. Regards -- Gerard 0001-Make-an-org-lint-warning-more-helpful.patch Description: Binary data
Re: [BUG] org-lint tells to move #+name to wrong place in results block
On 22.01.2024 19:15, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: For the listings below org-lint tells me to move "#+name: OUT" downwards: Line Trust Warning 17 high #+name: in results of evaluation will be replaced by re-evaluating the src block. Use #+name in the block instead. This is not true Good point. The real problem is indeed different - when the source block has :exports code, results will be removed and any links to OUT will become invalid: ..., but exporting says: Unable to resolve the link "OUT". FR: would it be possible to resolve such links? What is the purpose? Why not simply leaving the result name same as the source block? I have Python "IN" blocks generating Python "OUT" blocks that may end up on different pages after exporting to LaTeX and PDF. The FR would allow to link always to the correct page. I have 10 org-lint warnings of this type for a 150 page PDF document. Most of those "OUT" blocks are on the same page as their corresponding "IN" blocks, but I have worked around this limitation. I can live without the requested feature, but it would be a way to eliminate an org-lint test. Best regards -- Gerard
[BUG] org-lint tells to move #+name to wrong place in results block
For the listings below org-lint tells me to move "#+name: OUT" downwards: Line Trust Warning 17 high #+name: in results of evaluation will be replaced by re-evaluating the src block. Use #+name in the block instead. This is not true, and after I move it below "#+RESULTS: IN" re-evalution makes "#+name: OUT" disappear. #+header: :wrap "src emacs-lisp" #+name: IN #+begin_src emacs-lisp 3 #+end_src #+name: OUT #+RESULTS: IN #+begin_src emacs-lisp 3 #+end_src Listing [[IN]] produces listing [[OUT]], clicking each link in Org jumps to the linked block, TAB-bing on "#+name: OUT" folds the block, but exporting says: Unable to resolve the link "OUT". Org mode version 9.7-pre (release_9.6.17-1081-g83696b) FR: would it be possible to resolve such links? Regards -- Gerard
Re: [PATCH] Make command org-babel-detangle work interactively
On 20.01.2024 13:18, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: I suspect that you may have some misunderstanding about how `org-babel-detangle' works. Its docstring says: Propagate changes in source file back original to Org file. So, it is expected to run from the tangled file; not from the Org file. Yes, I misunderstood this and I see that my patch breaks this. I think there is a typo in the docstring: "original to" must become "to original" so that it ends with "back to original Org file". How about the attached patch? I have attached a modification of your patch. I think it is clearer with the risk of being too verbose, but the docstring width is < 80. 0001-lisp-ob-tangle.el-org-babel-detangle-Improve-docstri.patch Description: Binary data
Re: [PATCH] Make command org-babel-detangle work interactively
On 19.01.2024 16:20, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: org-babel-detangle is an interactive command but M-x org-babel-detangle always replies "Detangled 0 code blocks" This patch makes org-babel-detangle prompt for a source code file. Obviously, I got bitten by this. I suspect that you may have some misunderstanding about how `org-babel-detangle' works. Its docstring says: Propagate changes in source file back original to Org file. So, it is expected to run from the tangled file; not from the Org file. Yes, I misunderstood this and I see that my patch breaks this. I think there is a typo in the docstring: "original to" must become "to original" so that it ends with "back to original Org file".
Re: [PATCH] Patches for problems discovered with interactive testing
On 19.01.2024 13:50, Ihor Radchenko wrote:
gerard.vermeu...@posteo.net writes:
This patch addresses a number of glitches discovered during
interactive
testing and contains possible fixes (sub-patch test-ob-maxima fixes
batch testing on my system, but not interactive testing).
Thanks for your interest in improving Org mode tests!
The test-ob-maxima patch may be due to a different Maxima version, but
I do not think so. In batch testing test-ob-maxima passes contrary to
interactive mode.
On my side, Maxima tests pass both interactively and non-interactively.
I use Maxima 5.47.0
What is your version?
The same: maxima --version
Maxima 5.47.0
In batch testing without the patch I get:
Test ob-maxima/batch+verbatim condition:
(ert-test-failed
((should
(equal (org-babel-execute-src-block)
"(assume(z > 0),integrate(exp(-t)*t^z,t,0,inf))\n
gamma(z + 1)"))
:form
(equal
"(linenum:0,\n(assume(z > 0),integrate(exp(-t)*t^z,t,0,inf))\n
gamma(z + 1)"
"(assume(z > 0),integrate(exp(-t)*t^z,t,0,inf))\n
gamma(z + 1)")
:value nil :explanation
(arrays-of-different-length 104 92
"(linenum:0,\n(assume(z >
0),integrate(exp(-t)*t^z,t,0,inf))\n
gamma(z + 1)"
"(assume(z >
0),integrate(exp(-t)*t^z,t,0,inf))\n
gamma(z + 1)"
first-mismatch-at 1)))
FAILED 162/1252 ob-maxima/batch+verbatim (0.694916 sec) at
../lisp/test-ob
-maxima.el:71
I do not know where the difference comes from. I am not a Maxima user
and not inclined to track this down unless you tell me it is important.
The test-ob-python patch unsets org-src-preserve-indentation which I
have set.
The test-ob patch also unsets org-src-preserve-indentation.
The test-org patch also unsets org-src-preserve-indentation. This
reduces the number of failures to 2 while testing test-org
interactively.
It is generally not expected that Org tests will pass when you try to
run them on Emacs instance with your personal config. This is because
you can have arbitrary customizations, hooks, or advices that change
the
Org mode defaults.
let-binding a couple of variables cannot fix this general problem for
all scenarios. So, I do not see any reason to accept patches that make
the tests run with personal config of a single user.
Before I made the patch, I had reverted changes that worked
interactively
in my personal config but caused failures with make test.
Because of the Maxima test failure (also in batch), I was not sure that
all
tests pass on a reference system.
What might be useful, however, is making sure that tests do not fail
interactively with a clean Emacs config (make repro).
Check out testing/README file.
I have a super-weird system where make repro opens Emacs with
as default-directory my home directory. So I have to make symbolic
links from my home to the testing and lisp directories.
But make test works.
Because of testing my
0001-org-babel-demarcate-block-split-using-element-API.patch
interactively in my personal config (before make test which takes
quite some time), I figured out that it would guess to suppress false
failures.
(ert-deftest ob-maxima/string-input ()
"Test of string input"
(org-test-at-id "b5842ed4-8e8b-4b18-a1c9-cef006b6a6c8"
(org-babel-next-src-block 2)
-(should (equal "- sin(x)" (org-babel-execute-src-block)
+(should (equal '(("(linenum:0," "") ("-" "sin(x)"))
+ (org-babel-execute-src-block)
The test in question is testing the output of
#+begin_src maxima :var fun="sin(x)" :var q=2 :results silent
print(diff(fun, x, q))$
#+end_src
It is certainly not expected that such code block returns "linenum:0".
I would say that it is an unexplained difference, I still get (with
"linenum:0") :
#+header: :wrap "src text -n"
#+name: lst:maxima-example
#+begin_src maxima -n :batch batch :cmdline --quiet :exports both
:results raw
rat(1/(x+1) + x/(x-1));
#+end_src
#+name: lst:maxima-example-results
#+results: lst:maxima-example
#+begin_src text -n
(%i1) (linenum:0,
(%i1) rat(1/(x+1)+x/(x-1))
2
x + 2 x - 1
(%o1)/R/
2
x - 1
#+end_src
Tests in Org mode are verifying that Org mode behaves correctly. It
makes no sense to change the test when Org mode result is not correct -
we should instead fix Org mode.
In the majority of cases, if the test is failing, it is not something
wrong with the test, but something wrong with Org mode code that test
is
verifying.
(ert-deftest test-ob/does-not-replace-a-block-with-the-results ()
(org-test-with-temp-text "#+NAME: foo
diff
[PATCH] Make command org-babel-detangle work interactively
Hi, org-babel-detangle is an interactive command but M-x org-babel-detangle always replies "Detangled 0 code blocks" This patch makes org-babel-detangle prompt for a source code file. Obviously, I got bitten by this. The patch contains (user-error "Source code file does %S not exist" source-code-file) so it may break code that uses org-babel-detangle in a loop. I prefer an user-error, but others may not. Regards -- Gerard 0001-Make-command-org-babel-detangle-work-interactively.patch Description: Binary data
[PATCH] Patches for problems discovered with interactive testing
This patch addresses a number of glitches discovered during interactive testing and contains possible fixes (sub-patch test-ob-maxima fixes batch testing on my system, but not interactive testing). The test-ob-maxima patch may be due to a different Maxima version, but I do not think so. In batch testing test-ob-maxima passes contrary to interactive mode. The test-ob-python patch unsets org-src-preserve-indentation which I have set. The test-ob patch also unsets org-src-preserve-indentation. The test-org-element patch indicates something weird on my system, I want to report. Should not be applied. The test-org patch also unsets org-src-preserve-indentation. This reduces the number of failures to 2 while testing test-org interactively. Sorry to put them all together, but I do not know how to handle (ma)git to keep the patches apart. Regards -- Gerard 0001-Patches-for-problems-discovered-with-interactive-tes.patch Description: Binary data
Re: [BUG] defaults make it hard to edit Elisp blocks in org buffers
On 18.01.2024 17:45, Sébastien Miquel wrote: 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. As far as I understand, the effect also occurs when the block has a common indentation. Below are the steps: With this settings: #+begin_src emacs-lisp -i :results silent (setopt org-adapt-indentation nil org-src-preserve-indentation nil org-edit-src-content-indentation 2) #+end_src And with POINT after "?" and typing ENTER (wait more than 1 second for automatic indenting of 2 spaces), I can type parentheses with some sort of common indentation like below: #+begin_src emacs-lisp ;; common indentation? (()) (()) (()) #+end_src When I place POINT in the middle of the lowest parentheses and type ENTER, then everything moves 2 spaces to the right like below: #+begin_src emacs-lisp ;; common indentation? (()) (()) (( )) #+end_src I think, this is different of what you are saying. Looking at the code, I inferred that I can kill this behavior with the `-i' switch, and that works. Regards -- Gerard
[BUG] defaults make it hard to edit Elisp blocks in org buffers
* Why I do (setopt org-src-preserve-indention t) Sometimes, I want to do small Elisp edits without calling org-edit-source-code. Below, I describe a long standing bug (several years) that is also present in main. I use smartparens, but it reproduces also in a clean environment (minimal init.el) using main. #+begin_src emacs-lisp :results silent (setopt org-edit-src-content-indentation 4 ;; to amplify the effect org-src-preserve-indentation nil) #+end_src Place point after the first open parenthesis below and type return. #+begin_src emacs-lisp (()) #+end_src This moves the code 4 spaces to the right. Place point after the first open parenthesis of the lowest line below and type return. #+begin_src emacs-lisp ( ( )) #+end_src This moves the code again 4 spaces to the right. It does not matter whether the the parentheses contain for instance a function definition. * Therefore, I work with those settings breaking the default. #+begin_src emacs-lisp :results silent (setopt org-edit-src-content-indentation 2 org-src-preserve-indentation t) #+end_src Place point after the first open parenthesis below and type return. #+begin_src emacs-lisp (()) #+end_src The parentheses remain left-shifted. Place point after the first open parenthis of the lowest line below and type return. #+begin_src emacs-lisp ( ()) #+end_src Again, the parentheses remain left-shifted. #+begin_src emacs-lisp ( ( )) #+end_src The parentheses remain left-shifted. I prefer this over the default. I have only seen it with Elisp blocks. Regards -- Gerard
Re: [PATCH] org-babel-demarcate-block: split using element API
On 14.01.2024 20:18, gerard.vermeu...@posteo.net wrote: On 14.01.2024 13:16, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: [...] I tried make test and the tests are still failing with this new patch: 1 unexpected results: FAILED test-ob/demarcate-block ((should (string= region-text (org-trim (nth 1 info :form (string= "mark this line as region" "") :value nil :explanation (arrays-of-different-length 24 0 "mark this line as region" "" first-mismatch-at 0)) This is a tough lesson: the tests pass always on my system. I think the failure you see is related to a problem marking a region in my test code (wish: support in `org-test-with-temp-text' for "" besides "", but maybe that depends on ERT), else the problem would have shown up while testing the patch interactively. I think that I have improved my region marking code by using "" in the temp-text as a start. Then, I only have to find where to set mark, and eventually exchange point and mark. The test code now checks (mark) in the 3 places where a region is marked. This looks superfluous if the code is really robust, but at least it checks whether the region marking is (or was) the problem. To converge faster, I have split the test into 6 tests: test-ob/demarcate-block-split-duplication test-ob/demarcate-block-split-prefix-point test-ob/demarcate-block-split-prefix-region test-ob/demarcate-block-split-user-errors test-ob/demarcate-block-wrap-point test-ob/demarcate-block-wrap-region The test failure on your system was due to the sub-test that is now test-ob/demarcate-block-wrap-region Regards -- Gerard 0001-org-babel-demarcate-block-split-using-element-API.patch Description: Binary data
Re: [PATCH] org-babel-demarcate-block: split using element API
On 14.01.2024 13:16, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: [...] I tried make test and the tests are still failing with this new patch: 1 unexpected results: FAILED test-ob/demarcate-block ((should (string= region-text (org-trim (nth 1 info :form (string= "mark this line as region" "") :value nil :explanation (arrays-of-different-length 24 0 "mark this line as region" "" first-mismatch-at 0)) This is a tough lesson: the tests pass always on my system. I think the failure you see is related to a problem marking a region in my test code (wish: support in `org-test-with-temp-text' for "" besides "", but maybe that depends on ERT), else the problem would have shown up while testing the patch interactively. I think that I have improved my region marking code by using "" in the temp-text as a start. Then, I only have to find where to set mark, and eventually exchange point and mark. The test code now checks (mark) in the 3 places where a region is marked. This looks superfluous if the code is really robust, but at least it checks whether the region marking is (or was) the problem. New patch attached. Some of the scaffolding (should ...) forms could be removed if the 5 sub-test in test-ob/demarcate-block would be 5 separated ERT tests. I prefer to continue like this and do eventual refactoring later. Regards -- Gerard 0001-org-babel-demarcate-block-split-using-element-API.patch Description: Binary data
Re: [PATCH] org-babel-demarcate-block: split using element API
On 13.01.2024 21:16, gerard.vermeu...@posteo.net wrote: On 13.01.2024 16:17, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: Attached you'll find a new patch addressing all you issues. Thanks! I tried to run make test, and I am getting FAILED test-ob/demarcate-block ((should (string= region-text (org-trim (nth 1 info :form (string= "mark this line as region" "") :value nil :explanation (arrays-of-different-length 24 0 "mark this line as region" "" first-mismatch-at 0)) I have improved a regexp used to mark a region in this sub-test improving the robustness of the code. Furthermore, I have replaced all occurrences of (set-mark (point)) with (set-mark-command nil), but I doubt that this is the reason. Nevertheless, I feel I need to point out the limitation of this particular test case. [...] The text after (mark) and (point) is misaligned. I tend to mark regions in a way that is compatible with the patch, but some users won't (maybe they are willing to adapt). Patch attached. I found a way to preserve the (current-column) of text after point and mark in the element API code so that point or region splitting behaves like main where the (current-column)'s remain preserved naturally. I think this is preferable with respect to the previous patch (at least it does not break the expectations of current users). It allowed a minor simplification of the sub-test that failed in your case. New patch attached. Regards -- Gerard 0001-org-babel-demarcate-block-split-using-element-API.patch Description: Binary data
Re: [PATCH] org-babel-demarcate-block: split using element API
On 13.01.2024 16:17, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: Attached you'll find a new patch addressing all you issues. Thanks! I tried to run make test, and I am getting FAILED test-ob/demarcate-block ((should (string= region-text (org-trim (nth 1 info :form (string= "mark this line as region" "") :value nil :explanation (arrays-of-different-length 24 0 "mark this line as region" "" first-mismatch-at 0)) I have improved a regexp used to mark a region in this sub-test improving the robustness of the code. Furthermore, I have replaced all occurrences of (set-mark (point)) with (set-mark-command nil), but I doubt that this is the reason. Nevertheless, I feel I need to point out the limitation of this particular test case. Prerequisites: #+begin_src emacs-lisp :results silent (setopt org-adapt-indentation t org-edit-src-content-indentation 2 org-src-preserve-indentation nil) #+end_src When I mark really the line containing "mark this line as region" C-u C-C C-v C-d works nicely (done in the sub-test). ** 10 stars with region between two lines #+header: :var b="also seen" #+begin_src any-language -i -n :var a="seen" to upper block mark this line as region to lower block #+end_src but C-u C-c C-v C-d after marking ' this line as ' produces this: ** 10 stars with region between two lines #+header: :var b="also seen" #+begin_src any-language -i -n :var a="seen" to upper block mark #+end_src ** #+header: :var b="also seen" #+begin_src any-language -i -n :var a="seen" this line as #+end_src ** #+header: :var b="also seen" #+begin_src any-language -i -n :var a="seen" region to lower block #+end_src The text after (mark) and (point) is misaligned. I tend to mark regions in a way that is compatible with the patch, but some users won't (maybe they are willing to adapt). Patch attached. Regards -- Gerard 0001-org-babel-demarcate-block-split-using-element-API.patch Description: Binary data
Re: [PATCH] org-babel-demarcate-block: split using element API
Attached you'll find a new patch addressing all you issues. I have integrated our discussion leading to https://list.orgmode.org/87ply6nyue.fsf@localhost/ Please feel free to add the line Co-authored-by: Ihor Radchenko to the commit message. I think you should. On 09.01.2024 15:49, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: Attached you'll find a new patch fixing the three wrong lines in the previous and now the ERT test checks also for `user-error's. Thanks! 2. Your patch does not create space between the src blocks, unlike what we have on main. I think that you need to (1) create a single blank lines between blocks (set :post-blank property to 1); (2) keep the number blank lines after the last block the same as in the initial block (copy the :post-blank property and assign it to the last inserted src block). For C-u argument, do not do anything special - just keep the original :post-blank as is. It is the closest to what we have on main. The previous version of the patch had +(insert (if arg (concat stars "\n") "")) and now it has +(insert (if arg (concat stars "\n") "\n")) I prefer this over setting the :post-blank property because it is simpler. Yet, it will lead to large spacing between src blocks in the following scenario: #+begin_src emacs-lisp "This is test" "This is test2" "This is test3" #+end_src Paragraph. I have used the :post-blank property to fix it. The result is now: #+begin_src emacs-lisp "This is test" #+end_src #+begin_src emacs-lisp "This is test2" "This is test3" #+end_src Paragraph. Here is also a redone comparison between main and patch: --- begin comparison main and patch #+begin_src emacs-lisp :results silent (setopt org-adapt-indentation t org-edit-src-content-indentation 2 org-src-preserve-indentation nil)) #+end_src * main C-u C-x C-v C-d #+CAPTION: caption. #+NAME: name. #+BEGIN_SRC emacs-lisp above ;; region below #+END_SRC becomes C-u C-x C-v C-d #+CAPTION: caption. #+NAME: name. #+BEGIN_SRC emacs-lisp above #+END_SRC #+BEGIN_SRC emacs-lisp ;; region #+END_SRC #+BEGIN_SRC emacs-lisp below #+END_SRC pitfall * patch C-u C-x C-v C-d #+CAPTION: caption. #+NAME: name. #+BEGIN_SRC emacs-lisp above ;; region below #+END_SRC becomes C-u C-x C-v C-d #+caption: caption. #+name: name. #+begin_src emacs-lisp above #+end_src #+begin_src emacs-lisp ;; region #+end_src #+begin_src emacs-lisp below #+end_src pitfall --- end comparison main and patch Also, your new version of the patch will completely misbehave because of setting mark. Please, use `region-beginning' and `region-end' instead. Setting and checking mark is not to be done in Elisp - it only make sense when transient-mark-mode is enabled. Done. See below. * Adding a user option for properties to set to nil in org-element-copy. This may be overkill, but something like: #+begin_src emacs-lisp :results nil :tangle no (defcustom org-babel-demarcate-block-delete '(:caption :name) "List of things to delete from blocks below the upper block when splitting blocks by demarcation. Possible things are `:caption' to delete \"#+CAPTION:\" keywords, `:header' to delete \"#+HEADER:\" keywords, `:name' to delete \"#+NAME:\" keywords, and `switches' to delete e.g. \"-i +n 10\" from the \"#+BEGIN_SRC\" line." :group 'org-babel :package-version '(Org . "9.7") :type '(set :tag "Things to delete when splitting blocks by demarcation" (const :caption) (const :header) (const :name) (const :switches)) :initialize #'custom-initialize-default :set (lambda (sym val) (set-default sym val))) #+end_src That would make sense. Although, we do not have to limit the possible options to just what you listed. Arbitrary affiliated keywords might also be excluded. For example, #+ATTR_HTML keyword is stored in src block object as :attr_html. I prefer to postpone work on this idea. + ;; To simplify the (unless ... (user-error ...)). + (unless (org-region-active-p) (set-mark (point))) Setting mark causes issue in my above example. + ;; Test mark to be more specific than "Not at a block". + (unless (and (>= (point) body-beg) (<= (mark) body-end)) +(user-error "Select within the source block body to split it")) Here, it is better to use `region-beginning', `point', and `region-end'. `region-beginning', unlike mark and point, is guaranteed to be _before_ `region-end'. Mark may be before point, in contrast. You can write something like
Re: [BUG]: unexpected behavior related to org-indent-block
On 11.01.2024 18:28, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: You can also try cd /path/to/org/git make repro I get: Debugger entered--Lisp error: (void-function org-element-begin) (org-element-begin copy) This means that your Org mode git folder is not on main branch. You can try git checkout main or re-clone the Org repository: git clone https://git.savannah.gnu.org/cgit/emacs/org-mode.git/ This is the output of "git checkout" in my Org repository clone: python-3.11.7:0→vermeulen@bt-pc226:~/VCS/org-mode% git checkout (git)-[main]- Your branch is up to date with 'origin/main'. After "make repro" and (org-version) I get Org mode version 9.6.15 (release_9.6.15 @ /Users/vermeulen/opt/share/emacs/30.0.50/lisp/org/) Something else on my system makes "make repro" behave unexpectedly. If you still see the problem, we may need to narrow down the problem on your side using debugger. I have zero experience with the debugger. As the last resort, we can do it by screen sharing in BBB/Jitsi. OK. I have Jitsi installed on my system, but not much experience in screen sharing.
Re: [BUG]: unexpected behavior related to org-indent-block
On 11.01.2024 17:01, Ihor Radchenko wrote:
gerard.vermeu...@posteo.net writes:
Try using released Emacs version. Emacs master builds are a subject
of
unexpected bugs sometimes.
I get exactly the same results on Emacs-29.1 as on Emacs master.
For Emacs-29.1 (tar.xy) and Emacs master I have done (nothing
special):
LIBRARY_PATH=/usr/local/Cellar/libgccjit/13.2.0/lib/gcc/13 make
configure="--prefix=${HOME}/opt --disable-ns-self-contained"
Strange.
You can also try
cd /path/to/org/git
make repro
I get:
Debugger entered--Lisp error: (void-function org-element-begin)
(org-element-begin copy)
(delete-region (org-element-begin copy) (org-element-end copy))
(let ((copy (org-element-copy (org-element-at-point))) (n 0))
(delete-region (org-element-begin copy) (org-element-end copy)) (while
(< n 2) (cl-incf n) (org-element-put-property copy :value (format "copy
%s" n)) (insert (org-element-interpret-data copy)) (org-indent-block)))
make-2-indent-fails()
funcall-interactively(make-2-indent-fails)
command-execute(make-2-indent-fails record)
I think it is strange that org-element-begin is void.
If you still see the problem, we may need to narrow down the problem on
your side using debugger.
I have zero experience with the debugger.
Re: [BUG]: unexpected behavior related to org-indent-block
On 11.01.2024 16:04, Ihor Radchenko wrote:
gerard.vermeu...@posteo.net writes:
I cannot reproduce.
...
This is strange:
I pulled the latest main and created a clean org-emacs directory
where I put a minimal init.el reading:
...
I have no idea what I can do now.
My Emacs is also recent main and built by me with minimal configure
options.
Try using released Emacs version. Emacs master builds are a subject of
unexpected bugs sometimes.
I get exactly the same results on Emacs-29.1 as on Emacs master.
For Emacs-29.1 (tar.xy) and Emacs master I have done (nothing special):
LIBRARY_PATH=/usr/local/Cellar/libgccjit/13.2.0/lib/gcc/13 make
configure="--prefix=${HOME}/opt --disable-ns-self-contained"
Regards -- Gerard
Re: [BUG]: unexpected behavior related to org-indent-block
On 11.01.2024 13:37, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: Below, I show 2 commands to be run with point on a source block. I expect that those commands modify an Org file identically, but they do not. It fails when `org-indent-block' is called in a loop after each `(insert (org-element-interpret-data copy))' and it works when `org-indent-block' is called in a separate loop after insertion of all `(org-element-interpret-data copy)'s: ... Example block: --- #+begin_src emacs-lisp #+end_src --- make-2-indent-fails results in --- #+begin_src emacs-lisp copy 1 #+end_src I cannot reproduce. I am seeing make-2-indent-fails results in --- #+begin_src emacs-lisp copy 1 #+end_src #+begin_src emacs-lisp copy 2 #+end_src On the latest main. This is strange: I pulled the latest main and created a clean org-emacs directory where I put a minimal init.el reading: (when (eq system-type 'darwin) (setopt ns-alternate-modifier nil ns-command-modifier 'meta ns-right-command-modifier 'super)) (push (expand-file-name "~/VCS/org-mode/lisp") load-path) (require 'org) After emacs --init-directory org-emacs, I get (code in the result blocks got now indented): Example block: --- #+begin_src emacs-lisp #+end_src --- make-2-indent-fails results in --- #+begin_src emacs-lisp copy 1 #+end_src --- make-2-indent-works results in --- #+begin_src emacs-lisp copy 1 #+end_src #+begin_src emacs-lisp copy 2 #+end_src --- I have no idea what I can do now. My Emacs is also recent main and built by me with minimal configure options.
[BUG]: unexpected behavior related to org-indent-block
Below, I show 2 commands to be run with point on a source block. I expect that those commands modify an Org file identically, but they do not. It fails when `org-indent-block' is called in a loop after each `(insert (org-element-interpret-data copy))' and it works when `org-indent-block' is called in a separate loop after insertion of all `(org-element-interpret-data copy)'s: #+begin_src emacs-lisp :results silent (defun make-2-indent-fails () "Make 2 modified blocks, but fails." (interactive) (let ((copy (org-element-copy (org-element-at-point))) (n 0)) (delete-region (org-element-begin copy) (org-element-end copy)) (while (< n 2) (cl-incf n) (org-element-put-property copy :value (format "copy %s" n)) (insert (org-element-interpret-data copy)) (org-indent-block (defun make-2-indent-works () "Make 2 modified blocks, and works." (interactive) (let ((copy (org-element-copy (org-element-at-point))) (n 0)) (delete-region (org-element-begin copy) (org-element-end copy)) (while (< n 2) (cl-incf n) (org-element-put-property copy :value (format "copy %s" n)) (insert (org-element-interpret-data copy))) (org-previous-block n) (while (> n 0) (cl-decf n) (org-indent-block #+end_src Example block: --- #+begin_src emacs-lisp #+end_src --- make-2-indent-fails results in --- #+begin_src emacs-lisp copy 1 #+end_src --- make-2-indent-works results in --- #+begin_src emacs-lisp copy 1 #+end_src #+begin_src emacs-lisp copy 2 #+end_src --- I think that it is also weird that this bug does not show up in this ERT test while it does outside ERT: #+begin_src emacs-lisp :results silent (ert-deftest test-make-2-indent-fails () "Test unfolded `make-2-indent-fails'." (org-test-with-temp-text " ,#+begin_src emacs-lisp ,#+end_src " (let ((copy (org-element-copy (org-element-at-point))) (word "copy") (n 0)) (delete-region (org-element-begin copy) (org-element-end copy)) (while (< n 2) (cl-incf n) (org-element-put-property copy :value (format "%s %s" word n)) ;; Why does this work inside ERT and not outside ERT? (insert (org-element-interpret-data copy)) (org-indent-block)) (message "`%s'" (buffer-substring (point-min) (point-max))) (goto-char (point-min)) (while (> n 0) (cl-decf n) (should (re-search-forward word))) (should-not (re-search-forward word nil 'noerror) #+end_src Regards -- Gerard
Re: [PATCH] org-babel-demarcate-block: split using element API
On 09.01.2024 08:49, gerard.vermeu...@posteo.net wrote: [...] Anyhow, I have removed the comment and I have replaced check below it with + (set-mark (point)) ;; To simplify the next (unless ...): + (unless (and (>= (point) body-beg) (<= (mark) body-end)) +(user-error "Select within the source block body to split it")) which also protects against having point in body and mark on or below #+end_src It occurred to me to that I only should set mark to point when the region is not active. I will add checking for `user-error's to the ERT test. Attached you'll find a new patch fixing the three wrong lines in the previous and now the ERT test checks also for `user-error's. Regards -- Gerard 0001-org-babel-demarcate-block-split-using-element-API.patch Description: Binary data
Re: [PATCH] org-babel-demarcate-block: split using element API
On 08.01.2024 21:25, gerard.vermeu...@posteo.net wrote: On 08.01.2024 13:08, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: [...] Anyhow, I have removed the comment and I have replaced check below it with + (set-mark (point)) ;; To simplify the next (unless ...): + (unless (and (>= (point) body-beg) (<= (mark) body-end)) +(user-error "Select within the source block body to split it")) which also protects against having point in body and mark on or below #+end_src It occurred to me to that I only should set mark to point when the region is not active. I will add checking for `user-error's to the ERT test. Regards -- Gerard
Re: [PATCH] org-babel-demarcate-block: split using element API
On 08.01.2024 13:08, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: Attached you'll find a new version of my patch addressing all your issues. This mail ends with two other ideas in the context of this patch. [...] I've tested your patch and found two problems: 1. #+name: lines are duplicated, while they should not Of course. Sometimes I delete lines by a slip of the fingers. Thanks. 2. Your patch does not create space between the src blocks, unlike what we have on main. I think that you need to (1) create a single blank lines between blocks (set :post-blank property to 1); (2) keep the number blank lines after the last block the same as in the initial block (copy the :post-blank property and assign it to the last inserted src block). For C-u argument, do not do anything special - just keep the original :post-blank as is. It is the closest to what we have on main. The previous version of the patch had +(insert (if arg (concat stars "\n") "")) and now it has +(insert (if arg (concat stars "\n") "\n")) I prefer this over setting the :post-blank property because it is simpler. (main concats something like (if (arg stars "") "\n" ...). [...] Agreed, this is wrong. A partial explanation is that I attached too much value to the doc-string of `org-babel-get-src-block-info' telling "Return nil if point is not on a source block. Otherwise," which is for me in contradiction with documentation (string and start comment) in `org-babel-demarcate-block'. `org-babel-get-src-block-info' docstring were not wrong. You just missed the Org mode's convention that blank lines after src blocks or other syntax elements belong to these elements. That said, we may clarify the `org-babel-get-src-block-info' docstring to highlight this fact and avoid future confusion. I changed the docstring as you suggested below. Now demarcating with point below a source block works again and checking this is part of the ERT test. The ERT test does not check removing #+caption from the original block. Also, as I said above, we should remove #+name. The ERT test now checks that #+caption and #+name are removed from the original code. [...] Note that indentation of src blocks has been refactored recently on main. It should be more reliable now. If not, please report any issues. I will pay attention. -;; Copyright (C) 2009-2024 Free Software Foundation, Inc. +;; Copyright (C) 2009-2023 Free Software Foundation, Inc. This is a spurious change :) Reverted: it shows that I started editing in 2023 and that I am no good at git :) -Return nil if point is not on a source block. Otherwise, return -a list with the following pattern: +Return nil if point is not on a source block or not within blank +lines after a source block. Otherwise, return a list with the +following pattern: I'd rather say: Return nil if point is not on a source block (blank lines after a source block are considered a part of that source block). It would be more accurate. Done. +(let* ((copy (org-element-copy (org-element-at-point))) + (before (org-element-begin copy)) + (beyond (org-element-end copy)) + (parts (sort (if (org-region-active-p) +(list body-beg (mark) (point) body-end) + (list body-beg (point) body-end)) +#'<))) + ;; Prevent #+caption:, #+header:, and #+begin_src lines in block. This comment is out of place. Also, we do preserve #+header and #+begin_src lines, don't we? Maybe I should have written: + ;; Prevent #+caption:, #+header:, and #+begin_src lines in *body*. It prevents that when splitting with point at the # of #+caption a block like #+caption: caption #+name: name #+begin_src emacs-lisp ;; elisp code ... #+end_src the first block ends up with #+caption: caption #+name: name #+begin_src emacs-lisp ,#+caption: caption ,#+name: name ,#+begin_src emacs-lisp ;; elisp code ... #+end_src This is not easy to capture in a 1-2 line comment. Anyhow, I have removed the comment and I have replaced check below it with + (set-mark (point)) ;; To simplify the next (unless ...): + (unless (and (>= (point) body-beg) (<= (mark) body-end)) +(user-error "Select within the source block body to split it")) which also protects against having point in body and mark on or below #+end_src I think it covers everything that can be checked in the "splitting" branch. I think also that the "wrapping" branch can be better protected against similar region selection "user errors". I will come back on improving the "wrapping" branch shortly. And we need to remove #+name lines. Done. + (unless (and (>= (point) body-beg)) +(user-error "move point within the source block body to split it")) Please start error message from capital
Re: [PATCH] org-babel-demarcate-block: split using element API
On 04.01.2024 15:43, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: Attached you'll find a new version of the patch that addresses your comments. I have modified the ERT test so that it checks most of your examples showing where the older versions of the patch failed. The test is now called `test-ob/demarcate-block' It also allows to split in three blocks when a region is selected (main does this contrary to my older patches). Below, I compare region splitting using main or my patch. White-space differs between main and the patch and one might argue that the result produced by the patch is more consistent. Maybe, the indenting of the input code block is somewhat contrived, because all code is moved completely to the left after calling `org-indent-block'. * main does this #+begin_src emacs-lisp :results silent (setopt org-adapt-indentation t org-src-preserve-indentation t org-edit-src-content-indentation 2) #+end_src before C-u org-babel-demarcate-block region splitting #+begin_src emacs-lisp (defun above () (message "above")) (defun region () (message "mark region with leading and trailing blank lines")) (defun below () (message "below")) #+end_src after C-u org-babel-demarcate-block region splitting #+begin_src emacs-lisp (defun above () (message "above")) #+end_src #+begin_src emacs-lisp (defun region () (message "mark region with leading and trailing blank lines")) #+end_src #+begin_src emacs-lisp (defun below () (message "below")) #+end_src * end main does this * patch does this #+begin_src emacs-lisp :results silent (setopt org-adapt-indentation t org-src-preserve-indentation t org-edit-src-content-indentation 2) #+end_src before C-u org-babel-demarcate-block region splitting #+begin_src emacs-lisp (defun above () (message "above")) (defun region () (message "mark region with leading and trailing blank lines")) (defun below () (message "below")) #+end_src after C-u org-babel-demarcate-block region splitting #+begin_src emacs-lisp (defun above () (message "above")) #+end_src #+begin_src emacs-lisp (defun region () (message "mark region with leading and trailing blank lines")) #+end_src #+begin_src emacs-lisp (defun below () (message "below")) #+end_src * end patch does this I have tried to clean up the code. I have also tried to get `body-beg' and `body-end' marking the text between the #+begin_src and #+end_src lines from the element API, but I failed and had to fall back to `org-babel-where-is-src-block-head'. But only for that. org-element API does not provide this information for now. Maybe it is a good opportunity to alter the parser, so that code boundaries are provided... (defun org-babel-demarcate-block ( arg) ... -When called within blank lines after a code block, create a new code -block of the same language with the previous." Is there any reason why you dropped this feature? When I try #+begin_src emacs-lisp (+ 1 2) #+end_src M-x org-babel-demarcate-block throws an error with your patch. It creates a new block with the same language before your patch. Agreed, this is wrong. A partial explanation is that I attached too much value to the doc-string of `org-babel-get-src-block-info' telling "Return nil if point is not on a source block. Otherwise," which is for me in contradiction with documentation (string and start comment) in `org-babel-demarcate-block'. I have patched the doc-string of `org-babel-get-src-block-info' to add the "blank lines below condition". This patch reverts all changes that are due to my misunderstanding of what `org-babel-get-src-block-info' does. Now demarcating with point below a source block works again and checking this is part of the ERT test. + (let ((copy (org-element-copy (org-element-at-point))) +(stars (concat (make-string (or (org-current-level) 1) ?*) " "))) +(if (eq 'src-block (car copy)) You can instead use `org-element-type-p' This is now back to the original (if (and info start) ;; At src block, but ... +;; Keep this branch in sync with test-ob/demarcate-block-split. +;; _start is never nil, since there is a source block element at point. May you elaborate what you mean by "keep in sync"? "keep in sync" is a kind of reminder to myself, because I think that test-ob/demarcate-block-split was fragile wrt where point is after demarcation. The test is now called test-ob/demarcate-block and I tried to make it more robust. +(let* ((_start (org-babel-where-is-src-block-head)) Are
[BUG] org-lint shows strange spurious message before exporting to LaTeX
Hi, when I have an org file with a line like #+cite_export: biblatex phys,biblabel=brackets,doi=true and I invoke org-lint before I have exported the file to LaTeX, then org-lint complains: 9 nil Unknown cite export processor %S This strange message goes away when I invoke org-lint after I have exported the file to LaTeX. It is a minor annoyance, now I know how to make the message disappear, but before I knew that, I thought there may be something wrong with my #+cite_export: ... instead of org-lint using some information produced during the LaTeX export. I have no idea how to fix this. Regards -- Gerard
Re: [PATCH] org-babel-demarcate-block: split using org-element instead of regexp
On 03.01.2024 16:11, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: [...] Attached you'll find a new patch that seems to solve the block indentation problem that you have pointed out, see PS or attached patch-demo.org. test-ob/demarcate-block-split passes. This was a bug in `org-element-copy'. Fixed, on main now. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=dfeff03c5 I did not yet pull your change. Nevertheless, the Emergency exit errors have disappeared. [...] I made some adjustments to the patch, making use of org-element API. See the attached updated version of the patch. This patch is heavily edited and I think I did not forget any of your changes. I have tried to clean up the code. I have also tried to get `body-beg' and `body-end' marking the text between the #+begin_src and #+end_src lines from the element API, but I failed and had to fall back to `org-babel-where-is-src-block-head'. But only for that. I am not yet merging it as I found some weirdness with indentation. Consider the following (indentation is important): #+BEGIN_SRC emacs-lisp -n 20 ;; This exports with line number 20. (message "This is line 21") #+END_SRC After M-x org-babel-demarcate-block, I am getting #+BEGIN_SRC emacs-lisp -n 20 ;; This exports with line number 20. #+END_SRC #+begin_src emacs-lisp -n 20 (message "This is line 21") #+end_src See PS or patch-demo.org: PS (hope you read it with a mono-spaced font): #+begin_src emacs-lisp :results silent (setopt org-adapt-indentation t org-src-preserve-indentation nil org-edit-src-content-indentation 2) #+end_src before C-u org-babel-demarcate-block splitting I put point at the left of the last line in this block before splitting #+BEGIN_SRC emacs-lisp -n 20 ;; this exports with line number 20 (message "This exports with line number 21") #+END_SRC C-u C-c C-v d gets the stars right and the indentation after C-u org-babel-demarcate-block splitting I put point at the left of the last line in this block before splitting #+begin_src emacs-lisp -n 20 ;; this exports with line number 20 #+end_src #+begin_src emacs-lisp -n 20 (message "This exports with line number 21") #+end_src C-u C-c C-v d gets the stars right and the indentation 0001-org-babel-demarcate-block-split-using-org-element-in.patch Description: Binary data patch-demo.org Description: Binary data
Re: [PATCH] org-babel-demarcate-block: split using org-element instead of regexp
On 02.01.2024 11:48, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: [...] IMHO, this is a bug. The current approach with regexp matching in `org-babel-demarcate-block' is clearly not accurate. What would be more robust is using org-element-at-point + org-element-copy + set :value + org-element-interpret-data to carry over all the affiliated keywords and header arguments. [...] (org-babel--get-vars (nth 2 (org-babel-get-src-block-info))) Attached you'll find a new patch trying to implement your suggestions. Interactive splitting by demarcation seems to work quite well (see the before and after splitting snippets in the PS). However, I cannot run the test because org-babel-demarcate-block always errors "org-element--cache: Emergency exit" while the same input works interactively. Could there be a problem of cache synchronization or something like that? Is there something I can do? I also did not yet look into how to propagate a switch like -n10. PS: # begin before splitting snippet #+caption[Demarcation splitting test]: #+caption: Demarcation splitting test. #+header: :var edge="also copied" #+header: :wrap "src any-spanish -n" #+name: lst:test #+begin_src python -i -n :var here="copied" :wrap "src any-english -n" # above-split # below-split #+end_src # end before splitting snippet # begin after splitting snippet #+caption[Demarcation splitting test]: #+caption: Demarcation splitting test. #+header: :var edge="also copied" #+header: :wrap "src any-spanish -n" #+name: lst:test #+begin_src python -i -n :var here="copied" :wrap "src any-english -n" # above-split #+end_src #+header: :var edge="also copied" #+header: :wrap "src any-spanish -n" #+begin_src python -i -n :var here="copied" :wrap "src any-english -n" # below-split #+end_src # end after splitting snippet 0001-org-babel-demarcate-block-split-using-org-element-in.patch Description: Binary data
Re: [PATCH] org-babel-demarcate-block: duplicate switches too
On 31.12.2023 15:28, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: The purpose of this patch is to duplicate switches when org-babel-demarcate-block duplicates headers (meaning point in the source block when demarcating). Thanks for the patch! Would you mind also adding a test for `org-babel-demarcate-block' in testing/lisp/test-ob.el? I have attached a new patch with a test named `test-ob/demarcate-block-split'. Besides testing the duplication of switches and some header arguments, it also shows that multi-line header arguments are not duplicated. Whether this is a bug or a feature in `org-babel-demarcate-block' may be a point of discussion. I have no real opinion. The code of the 4 (should ...) forms in the test below the line ;; unduplicated multi-line header arguments: feels a bit clumsy. Does Org have a function to extract the value that a particular var-name has from the association list returned by `org-babel-get-src-block-info'? Regards -- Gerard Regards 0001-org-babel-demarcate-block-duplicate-switches-too.patch Description: Binary data
[PATCH] org-babel-demarcate-block: duplicate switches too
Hi, The purpose of this patch is to duplicate switches when org-babel-demarcate-block duplicates headers (meaning point in the source block when demarcating). Regards -- Gerard 0001-org-babel-demarcate-block-duplicate-switches-too.patch Description: Binary data
[BUG] using ob-maxima makes org-lint produce an error
Hi, org-lint errors when using ob-maxima as the following snippet shows: # begin Org snippet org-lint errors with "Wrong type argument: listp, batchload" after evaluating: #+begin_src emacs-lisp :results silent (require 'ob-maxima) #+end_src org-lint shows its *Org Lint* buffer after evaluating: #+begin_src emacs-lisp :results silent (unload-feature 'ob-maxima) #+end_src #+header: :wrap "src text" #+begin_src maxima :batch batch :cmdline --quiet :exports both :results raw rat(1/(x+1) + x/(x-1)); #+end_src #+RESULTS: #+begin_src text (%i1) (linenum:0, (%i1) rat(1/(x+1)+x/(x-1)) 2 x + 2 x - 1 (%o1)/R/ 2 x - 1 #+end_src # end Org snippet Regards -- Gerard
[PATCH] Fix obsolete sleep-for usage
Hi, Emacs-30 obsoletes the second integer 'millisec' argument of 'sleep-for' and tells to use a float argument. This patch fixes the obsolete usage. Regards -- Gerard 0001-Fix-obsolete-sleep-for-usage.patch Description: Binary data
[PATCH] ob-fortran.el: Fix name of caller in documentation
Hi, This patch fixes an oversight in 765a84ea252fd7f281340c40fdc97f696f8cac33 It fixes the caller name in documentation and conforms to "rules" in sibling ob-XXX.el files. Regards -- Gerard 0001-ob-fortran.el-Fix-name-of-caller-in-documentation.patch Description: Binary data
Re: [PATCH] ob-python results handling for dicts, dataframes, arrays, and plots
On 18.08.2023 06:37, gerard.vermeu...@posteo.net wrote: On 17.08.2023 14:10, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: Your patches allow anyone to change org-babel-python--def-format-value. For instance, I want to use black to "pretty-print" certain tree-like structures May you simply add an extra code to transform output as needed? Yes, it is a way to switch between Jack's first and second set of patches if one would like. Or to add code to transform other Python data structures. I take back the switching between Jack's first and second set of patches, but I stand by "to add code to transform other Python data structures".
Re: [PATCH] ob-python results handling for dicts, dataframes, arrays, and plots
On 17.08.2023 14:10, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: Your patches allow anyone to change org-babel-python--def-format-value. For instance, I want to use black to "pretty-print" certain tree-like structures May you simply add an extra code to transform output as needed? Yes, it is a way to switch between Jack's first and second set of patches if one would like. Or to add code to transform other Python data structures.
Re: [PATCH] ob-python results handling for dicts, dataframes, arrays, and plots
On 17.08.2023 06:04, Jack Kamm wrote: I attach a 2nd patch implementing this. It also makes ":results table" the default return type for dict. (Use ":results verbatim" to get the dict as a string instead). I am also putting a branch with these changes here: https://github.com/jackkamm/org-mode/tree/python-results-revisited-2023 Happy to see that ob-python gets so much love! Your patches allow anyone to change org-babel-python--def-format-value. For instance, I want to use black to "pretty-print" certain tree-like structures and I have now in my init.el: (with-eval-after-load 'ob-python (setq org-babel-python--def-format-value "\ def __org_babel_python_format_value(result, result_file, result_params): with open(result_file, 'w') as f: if 'graphics' in result_params: result.savefig(result_file) elif 'pp' in result_params: import black f.write(black.format_str(repr(result), mode=black.Mode())) else: if not set(result_params).intersection(\ ['scalar', 'verbatim', 'raw']): try: import pandas except ImportError: pass else: if isinstance(result, pandas.DataFrame): result = [[''] + list(result.columns), None] + \ [[i] + list(row) for i, row in result.iterrows()] elif isinstance(result, pandas.Series): result = list(result.items()) try: import numpy except ImportError: pass else: if isinstance(result, numpy.ndarray): result = result.tolist() f.write(str(result))")) Without your patches I use advice to override org-babel-python-format-session-value, which is worse IMO. This also allows anyone to format for instance AstroPy tables (https://docs.astropy.org/en/stable/table/). I do not know how much this "abuse" of defconst is frowned upon (elisp manual says defconst is advisory), but maybe it can be advertised as a feature. Best regards -- Gerard
Re: inconsistency links and code line labels
On 06.07.2023 14:49, Dan Drake wrote: There's a bug [[(my-code-line-label)][right here]]. This seems inconsistent. Why do I have to omit the ref: bit? This always confuses me; it seems like it would be simpler to just make the label and the links to that line of code be exactly the same. I don't see any particular reference to this in the org manual (https://orgmode.org/manual/Internal-Links.html [2]). Any insights? My idea would be to get rid of the special behavior for code line labels and just make this work with dedicated targets: in regular parts of my org file, I use <> and can make links to that. It would be simple and consistent to make that also work the same when <> is inside a code block. Such link targets would conflict with <> references See: https://orgmode.org/manual/Noweb-Reference-Syntax.html Therefore something like the behavior described in https://orgmode.org/manual/Literal-Examples.html must have been invented (look at the description of the -n, -r, and -l switches). Regards -- Gerard
[PATCH] org: fix symbol names and grammar in docstrings
Hi, The docstrings of `org-outline-level' and `org-current-level' contain the undefined symbol name `org-odd-levels'. The same lines of the docstrings contain also wording like "Unlike to `org-current-level'" and "Unlike to `org-outline-level'" where "to" should not be there. This patch changes the symbol names to `org-odd-levels-only' and removes the "to" typos. Regards -- Gerard 0001-org-fix-symbol-names-and-grammar-in-docstrings.patch Description: Binary data
Re: [PATCH] ox-html.el: add option to embed SVG for CSS support in SVG
On 17.06.2023 14:38, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: The term "image in-lining" is a very terse description of what my code does. ... Before going ahead with a patch to in-line images in tags, there remains the question of how to make those tags behave as much as possible as tags. My knowledge of HTML is very thin and Javascript even worse. I am afraid that I am reaching the limit of my HTML-fu. Let's wait for Timothy (ox-html maintainer) to review this. That is perfectly fine with me. I put this aside until after his review.
Re: [PATCH] ox-html.el: add option to embed SVG for CSS support in SVG
On 15.06.2023 22:51, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: On 07.06.2023 19:57, Ihor Radchenko wrote: I am not expert in html. Maybe someone else (Timothy?) can chime in. That said, I do not see why we cannot offer strategy as an option regardless whether is can solve the problem with CSS. ;; For each SVG image during HTML export: ;; 1. It checks `svg-as-object' and "image in-lining" whether to ;;embed the SVG image in an tag. ;; 2. If not, it checks `svg-inclusion' and "image in-lining" ;;whether to copy the SVG contents to the HTML output. ;; 3. If not, it falls back to checking "image in-lining" whether to ;;embed the SVG image in an tag (as any other image type). ;; 4. It is possible to set `svg-as-object' and/or `svg-inclusion': ;;- For each SVG link by means of "#+ATTR_HTML: :svg-as-object t" ;; or "#+ATTR_HTML: :svg-inclusion t". ;;- Within file scope by means of "#+OPTIONS: svg-as-object:t" or ;; "#+OPTIONS: svg-inclusion:t". ;;- Within toplevel scope by means of the options ;; `org-html-svg-as-object' or `org-html-svg-inclusion'. I think you missed `org-html-inline-image-rules' where users can include/exclude svg images from inlining. The term "image in-lining" is a very terse description of what my code does. In case of rules 1, 2, and 3 above: the code takes into account the two relevant options `org-html-inline-image' and `org-html-inline-image-rules' to decide whether the image would be in-lined in an tag. For rule 1 above: in case `svg-as-object' is also true, the code in-lines the image in an tag instead of an tag and returns the tag. In case `svg-as-object' is nil, apply rule 2. For rule 2 above: in case `svg-inclusion' is also true, return the SVG contents as a result. In case `svg-inclusion' is nil, apply rule 3. Rule 3 is applied by the normal "Image file" handling code from org-html-link in ox-html which handles `org-html-image-inline-rules', but my code for rules 1 and 2 do too. My clone of org-html-link is a copy with the exception that I added 4 lines of code (and 2 lines of comments) to implement the rules 1 and 2 (but we should not implement rule 2). Before going ahead with a patch to in-line images in tags, there remains the question of how to make those tags behave as much as possible as tags. My knowledge of HTML is very thin and Javascript even worse. Best regards -- Gerard
Re: [PATCH] ox-html.el: add option to embed SVG for CSS support in SVG
On 07.06.2023 19:57, Ihor Radchenko wrote: [...] I understand why you prefer the tag over the tag. Finally, I can see that there are ways to use CSS on img+svg: https://blog.union.io/code/2017/08/10/img-svg-fill/ I failed to make the flower example work with the information on this site. It could be my fault, but maybe also because the post targets the React framework since its subtitle reads "A Side Quest in Optimizing Performance for React". FWIW, here a brief description of how I solved my problem of making the MDN flower work taking into account the comments for improvement as far as I could. Thanks! https://forge.chapril.org/gav451/emacs.d/src/branch/main/site-lisp/ox-svg4css/ox-svg4css.el is a new derived backend for personal use. The commentary section of the backend and MWE follow below: #+begin_src emacs-lisp ;; This library implements an HTML derived backend for Org export. ;; It tries to address limitations of SVG images and CSS in HTML pages. ;; For each SVG image during HTML export: ;; 1. It checks `svg-as-object' and "image in-lining" whether to ;;embed the SVG image in an tag. ;; 2. If not, it checks `svg-inclusion' and "image in-lining" ;;whether to copy the SVG contents to the HTML output. ;; 3. If not, it falls back to checking "image in-lining" whether to ;;embed the SVG image in an tag (as any other image type). ;; 4. It is possible to set `svg-as-object' and/or `svg-inclusion': ;;- For each SVG link by means of "#+ATTR_HTML: :svg-as-object t" ;; or "#+ATTR_HTML: :svg-inclusion t". ;;- Within file scope by means of "#+OPTIONS: svg-as-object:t" or ;; "#+OPTIONS: svg-inclusion:t". ;;- Within toplevel scope by means of the options ;; `org-html-svg-as-object' or `org-html-svg-inclusion'. ;; ;; Caveats: the HTML output does not comply with W3C recommendations ;; after `svg-as-object' and/or `svg-inclusion' exports and it does not ;; comply with the Org Manual section "13.9.9 Images in HTML export" ;; after `svg-inclusion' exports. ;; ;; See: https://list.orgmode.org/c1eef10be815748d2103cb81bce08...@posteo.net/ ;; where Cristian Moe has proposed to embed SVG images in tags. ;; Ihor Radchenko and Max Nikulin have insisted on the use of special ;; "#+ATTR_HTML:" attributes to control the export options. ;; ;; I prefer enabling `:svg-as-object' over enabling `:svg-inclusion'. ;; ;; Relevant W3C documentation: ;; ;; Loading an SVG image by an HTML , or tag: ;; https://stackoverflow.com/a/12604286 ;; https://svgwg.org/specs/integration/#referencing-modes ;; https://svgwg.org/specs/integration/#embedded-document-mode ;; https://svgwg.org/specs/integration/#dynamic-interactive-mode ;; ;; Four types of SVG document usage with their security implications: ;; https://www.w3.org/wiki/SVG_Security #+end_src #+begin_src org :tangle mwe.org #+title: SVG and CSS MWE with svg4css backend using svg-as-object #+HTML_DOCTYPE: html5 The files =doc8.svg= and =style8.css= come from [[https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/SVG_and_CSS][SVG and CSS (MDN)]]. Open =doc8.svg= and =mwe.html= in Firefox to compare hovering over the flower. The flower remains fully black in case of an M-non-WE. #+ATTR_HTML: :svg-as-object t :title Does the flower work? #+CAPTION: Is MWE with SVG export in an tag instead of an tag. [[./doc8.svg]] # Note: the object tag requires to start the link with ./ to resolve it. #+end_src Best regards -- Gerard
Re: [PATCH] ox-html.el: add option to embed SVG for CSS support in SVG
On 06.06.2023 16:14, Max Nikulin wrote:
On 05/06/2023 20:23, gerard.vermeulen wrote:
# The next line overrules html-embed-svg:t
#+HTML_EMBED_SVG_EXCLUDES: ./doc8.svg
# The next line overrules html-embed-svg:nil
#+HTML_EMBED_SVG_INCLUDES: ./doc8.svg
I agree with Ihor's idea concerning #+attr_html (multiple inline
images in a paragraph may be an issue).
I think that inlining in the sense of ox-html is different from
embedding
as done in the patch. I may be wrong. This is the first point to
settle.
If I am right, I think that #+attr_html is not going to work.
However notice that some ox
options allows include/exclude lists:
:exclude-tags ("skip")
:with-drawers (not "skip")
I had been think about names like
:with-svgs-to-embed (...)
:sans-svgs-to-embed (...)
while preparing the patch. I decided to err towards verbosity.
You suggest that
:svgs-to-embed ("yes" "ok")
and
:svgs-to-embed (not "no" "skip")
are possible.
Is it also possible to do
#+EXCLUDE_TAGS: not "no" "skip"
or something similar in an Org file?
A can not add much to the discussions concerning various approaches to
include SVG images. I just faced that some SVG files breaks text
selection in Firefox: https://bugzilla.mozilla.org/1730723
I am using Firefox-113.0.2 and the bug is still there: sometimes
I can select all text from the beginning of the first "selecting"
downwards (depends on my touchpad sweep) but never from the
first "Start".
Re: [PATCH] ox-html.el: add option to embed SVG for CSS support in SVG
On 06.06.2023 11:57, Christian Moe wrote: Hi, I think there's a better approach. Tl;dr: - A better way to have active CSS in SVG images is to link to the external SVG file with the rather than tag, as we used to. - Without patching Org, you can embed an external SVG file as an SVG island in Org HTML export simply by using #+INCLUDE. Details: 1) Embedded SVG is not the only way to have active CSS etc. in SVG images. Linking to an external SVG file with an OBJECT element instead of IMG should work fine (tested in Firefox). You can test this by exporting Gerard's mwe.org example and editing the mwe.html to replace : img src="./doc8.svg" with : object type="image/svg+xml" data="./doc8.svg" Indeed, the flower works after the replacement but the caption disappears. I do not understand why, because the caption is still present in the HTML. Org used to use OBJECT for SVG years ago, but switched to IMG at some point. I'm not quite sure when or why that happened (forgive me for not doing an exhaustive search of the archive or delving into the git record). But I think perhaps the reason was this thread, https://lists.gnu.org/archive/html/emacs-orgmode/2016-07/msg00380.html where the issue was easy scaling, and that Jarmo Hurri's patch switching to IMG came to be applied at some point, even though Jarmo and I agreed that adding a common CLASS="svgfig" attribute to OBJECT would solve his issue, see this thread: https://lists.gnu.org/archive/html/emacs-orgmode/2016-07/msg00410.html I continue to think that OBJECT with an .svgfig class as default (or a setting to give the user a choice between IMG and OBJECT) is the best solution. 2) You can actually embed an SVG island in Org HTML export simply by using #+INCLUDE. To try this, add the following line to Gerard's mwe.org: : #+INCLUDE: "./doc8.svg" export html The exported HTML should now show the black flower from Gerard's minimal non-working example plus a working flower. Indeed, the flower works, but the caption disappears because Org does not recognize the "#+INCLUDE ..." as a link, the caption does not show up in the HTML. Is there an easy solution for this issue. (Some SVG files may start with an XML declaration; if the XML declaration is on a separate first line, you can just skip it by adding =:lines "2-"= to the #+INCLUDE instruction.) Yours, Christian Thanks -- Gerard Ihor Radchenko writes: gerard.vermeu...@posteo.net writes: I have been trying to export SVG images having links to CSS from Org to HTML and I have found that the this CSS is not active in Firefox (only browser I tried). I have found that the CCS is only active under two conditions: 1. The HTML page should manage the CSS that the SVG image links to. 2. The SVG image should be embedded in the HTML page. CCing Timothy, the maintainer. Also, does the above mean that Firefox does not support custom CSS user stylesheets? What am I missing? I wrote an ox-html derived export backend to embed SVG images: https://forge.chapril.org/gav451/emacs.d/src/branch/main/site-lisp/ox-my-html/ox-my-html.el and merged the SVG embedding functionality into ox-html.el leading to the attached patch. Thanks! I will provide high-level comments from general ox.el perspective. +(:html-embed-svg-excludes "HTML_EMBED_SVG_EXCLUDES" nil + org-html-embed-svg-excludes split) +(:html-embed-svg-includes "HTML_EMBED_SVG_INCLUDES" nil + org-html-embed-svg-includes split) This is awkward. To do per-image export adjustments, we usually use export attributes (#+ATTR_HTML: ...). And why "split"? +(:with-html-svg-embedding nil "html-embed-svg" org-html-embed-svg) We have :html-inline-images. Maybe better :html-embed-svg ? +(defcustom org-html-embed-svg nil ... + :version "30.0" We do not use :version tag. Please use :package-version. See Elisp manual section "15.1 Common Item Keywords". Also, maybe instead of t/nil boolean values here, we may allow the value to be a list of regular expressions or a string representing regular expression. This will allow what you are trying to do with HTML_EMBED_SVG_INCLUDES. The list elements might also be (not "..."), replicating HTML_EMBED_SVG_EXLCUDES. Even more generally, we may turn this into HTML_EMBED_IMAGES and embed all the images (possibly filtered by regexp). This will be slightly beyond the scope of this patch though. +(defun org-html--embed-svg-p (link path info) + "Check whether LINK and INFO specify to embed the SVG file named PATH. +LINK must have no contents and link to an SVG file. INFO may contain +lists of SVG files to include in and/or to exclude from embedding." + (and (not (org-element-contents link)) Please use `org-export-inline-image-p'. +(defun org-html-svg-contents (path) + "Return the SVG contents of the file named PATH." + (with-temp-buffer +(insert-file-contents path) +;; Delete text preceding
Re: [PATCH] ox-html.el: add option to embed SVG for CSS support in SVG
On 06.06.2023 09:49, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: I have been trying to export SVG images having links to CSS from Org to HTML and I have found that the this CSS is not active in Firefox (only browser I tried). I have found that the CCS is only active under two conditions: 1. The HTML page should manage the CSS that the SVG image links to. 2. The SVG image should be embedded in the HTML page. CCing Timothy, the maintainer. Also, does the above mean that Firefox does not support custom CSS user stylesheets? What am I missing? No, it means that custom CSS inside a linked SVG image is shielded from the page that has the link to the SVG image. To me it looks a natural defense against linking to different SVG images linking to conflicting custom CSS. If the HTML page linking to those images should manage the conflicting custom CSS, the creator of the page is responsible for resolving the conflicts. I wrote an ox-html derived export backend to embed SVG images: https://forge.chapril.org/gav451/emacs.d/src/branch/main/site-lisp/ox-my-html/ox-my-html.el and merged the SVG embedding functionality into ox-html.el leading to the attached patch. Thanks! I will provide high-level comments from general ox.el perspective. +(:html-embed-svg-excludes "HTML_EMBED_SVG_EXCLUDES" nil + org-html-embed-svg-excludes split) +(:html-embed-svg-includes "HTML_EMBED_SVG_INCLUDES" nil + org-html-embed-svg-includes split) This is awkward. To do per-image export adjustments, we usually use export attributes (#+ATTR_HTML: ...). And why "split"? I do not think that #+ATTR_HTML allows to embed (= copy) the contents of an SVG file directly into the HTML page. As far as I understand, it adds only attributes to HTML elements. The "split" is because of similarity with :select_tags and :exclude_tags in ox. It allows several files to be included in or excluded from embedding. I agree that an attribute like #+EMBED_SVG is less awkward. +(:with-html-svg-embedding nil "html-embed-svg" org-html-embed-svg) We have :html-inline-images. Maybe better :html-embed-svg ? I agree (the patch started as an derived backend with ox-beamer as an example where those kind of variables are prefixed with :with; this is a left-over). +(defcustom org-html-embed-svg nil ... + :version "30.0" We do not use :version tag. Please use :package-version. See Elisp manual section "15.1 Common Item Keywords". My fault. Also, maybe instead of t/nil boolean values here, we may allow the value to be a list of regular expressions or a string representing regular expression. This will allow what you are trying to do with HTML_EMBED_SVG_INCLUDES. The list elements might also be (not "..."), replicating HTML_EMBED_SVG_EXLCUDES. Even more generally, we may turn this into HTML_EMBED_IMAGES and embed all the images (possibly filtered by regexp). This will be slightly beyond the scope of this patch though. +(defun org-html--embed-svg-p (link path info) + "Check whether LINK and INFO specify to embed the SVG file named PATH. +LINK must have no contents and link to an SVG file. INFO may contain +lists of SVG files to include in and/or to exclude from embedding." + (and (not (org-element-contents link)) Please use `org-export-inline-image-p'. I think that the terminology "inline-image" in ox-html is confusing. In ox-html the result of the "inline-image" code is an HTML tag like It does not mean that image data is copied inline as with embedding. +(defun org-html-svg-contents (path) + "Return the SVG contents of the file named PATH." + (with-temp-buffer +(insert-file-contents path) +;; Delete text preceding something starting as an SVG root element. +;; The intent is to remove XML declarations (and XML comments). +;; This breaks in case of a preceding XML comment with inside +;; or a preceding XML element with an SVG element inside. +;; See https://emacs.stackexchange.com/a/57433 for the original code. But the original code is different, no? Yes, I pretend that my code is an improvement: 1. The with-syntax-table is superfluous. 2. The error message gives a reason and the filename causing it.
[PATCH] ox-html.el: add option to embed SVG for CSS support in SVG
Hi,
I have been trying to export SVG images having links to CSS from Org to
HTML
and I have found that the this CSS is not active in Firefox (only
browser I tried).
I have found that the CCS is only active under two conditions:
1. The HTML page should manage the CSS that the SVG image links to.
2. The SVG image should be embedded in the HTML page.
I wrote an ox-html derived export backend to embed SVG images:
https://forge.chapril.org/gav451/emacs.d/src/branch/main/site-lisp/ox-my-html/ox-my-html.el
and merged the SVG embedding functionality into ox-html.el leading to
the
attached patch.
I have included an MWE below and I attached mwe.org and mwe.html with
doc8.svg and style8.svg (showing a flower and chosen for the visual
impact).
You will get an M-non-WE after exporting mwe.org using ox-html on the
main branch.
# begin MWE
#+title: SVG and CSS MWE with patch or with ox-my-html backend
#+HTML_DOCTYPE: html5
#+HTML_HEAD:
#+OPTIONS: ^:{} toc:nil html-embed-svg:nil
# The next line overrules html-embed-svg:t
#+HTML_EMBED_SVG_EXCLUDES: ./doc8.svg
# The next line overrules html-embed-svg:nil
#+HTML_EMBED_SVG_INCLUDES: ./doc8.svg
[[https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/SVG_and_CSS][SVG
and CSS (MDN)]] is the origin of the files =doc8.svg= and
=style8.css=. Open =doc8.svg= and =mwe.html= in Firefox to compare
hovering over the flower. The flower is fully black in case of an
M-non-WE or in case of HTML export without patch or without ox-my-html
backend.
#+CAPTION: Is MWE with SVG embedding *and* with HTML_HEAD managing
#+CAPTION: the CSS. Becomes an M-non-WE without SVG embedding or
#+CAPTION: without HTML_HEAD managing the CSS.
[[./doc8.svg]]
# end MWE
Best regards -- Gerard
0001-ox-html.el-add-option-to-embed-SVG-for-CSS-support-i.patch
Description: Binary data
mwe.org
Description: Binary data
Title: SVG and CSS MWE with patch or with ox-my-html backend
SVG and CSS MWE with patch or with ox-my-html backend
SVG and CSS (MDN) is the origin of the files doc8.svg and
style8.css. Open doc8.svg and mwe.html in Firefox to compare
hovering over the flower. The flower is fully black in case of an
M-non-WE or in case of HTML export without patch or without ox-my-html
backend.
SVG demonstration
Mozilla CSS Getting Started - SVG demonstration
SVG demonstration
Move your mouse pointer over the flower.
Figure 1: Is MWE with SVG embedding and with HTML_HEAD managing the CSS. Becomes an M-non-WE without SVG embedding or without HTML_HEAD managing the CSS.
Author: Gerard Vermeulen
Created: 2023-06-05 Mon 11:10
Validate
/*** SVG demonstration ***/
/* page */
svg {
background-color: beige;
}
#heading {
font-size: 24px;
font-weight: bold;
}
#caption {
font-size: 12px;
}
/* flower */
#flower:hover {
cursor: crosshair;
}
/* gradient */
#fade-stop-1 {
stop-color: blue;
}
#fade-stop-2 {
stop-color: white;
}
/* petals */
.segment-fill {
fill: var(--segment-fill-fill);
stroke: var(--segment-fill-stroke);
stroke-width: var(--segment-fill-stroke-width);
}
.segment-fill:hover {
fill: var(--segment-fill-fill-hover);
stroke: var(--segment-fill-stroke-hover);
}
.segment-edge
Re: [PATCH] org-babel-load-languages: load unbound scheme-mode
On 11.05.2023 17:05, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: the attached patch fixes (setopt org-babel-load-languages '((scheme . t))) before scheme-mode has been loaded. Thanks, but may you please elaborate what is the problem you are trying to solve? I think that I have seen Emacs complaining about unbound scheme-mode when playing with ob-scheme, but I cannot reproduce it. I am sorry for the noise -- Gerard
[PATCH] org-babel-load-languages: load unbound scheme-mode
Hello, the attached patch fixes (setopt org-babel-load-languages '((scheme . t))) before scheme-mode has been loaded. Best regards -- Gerard 0001-org-babel-load-languages-load-unbound-scheme-mode.patch Description: Binary data
Re: Slashes inserted into Common Lisp code evaluation results
Igor, merged the patch yesterday with the bugfix branch. It is now in https://elpa.gnu.org/devel/org-9.7pre0.20230502.124756.tar or later. It should not matter whether you are using Emacs-28 or Emacs-29. Regards -- Gerard On 03.05.2023 08:00, Nathan Van Ymeren wrote: Ahh, I forgot to specify. I too use Sly in lieu of Slime, though I'm on emacs 28. That patch does not appear to have made its way into the prerelease I’m running. I will apply it manually later this evening and see how it goes. Thanks, N May 2, 2023 03:52:52 gerard.vermeu...@posteo.net: On 02.05.2023 08:18, Nathan Van Ymeren wrote: When I specify double width floats, they appear with slashes embedded in the RESULTS blocks, like so: #+begin_src lisp (+ 1 0.0002d0) #+end_src #+RESULTS: : 1\.0002d0 [...] Is this a bug? If not, how do I suppress this behaviour? Do you use SLIME? I use SLY on a recent emacs-29.0.90 build with a recent org-9.7pre. My result is (without the escaped dot): #+begin_src lisp (+ 1 0.0002d0) #+end_src #+RESULTS: : 1.0002d0 But I needed also to patch ob-lisp, see: https://list.orgmode.org/480536eb12bf49144384f4b1a85d8...@posteo.net/ In my opinion, SLY is friendlier out of the box than SLIME. Regards -- Gerard
Re: Slashes inserted into Common Lisp code evaluation results
On 02.05.2023 08:18, Nathan Van Ymeren wrote: When I specify double width floats, they appear with slashes embedded in the RESULTS blocks, like so: #+begin_src lisp (+ 1 0.0002d0) #+end_src #+RESULTS: : 1\.0002d0 [...] Is this a bug? If not, how do I suppress this behaviour? Do you use SLIME? I use SLY on a recent emacs-29.0.90 build with a recent org-9.7pre. My result is (without the escaped dot): #+begin_src lisp (+ 1 0.0002d0) #+end_src #+RESULTS: : 1.0002d0 But I needed also to patch ob-lisp, see: https://list.orgmode.org/480536eb12bf49144384f4b1a85d8...@posteo.net/ In my opinion, SLY is friendlier out of the box than SLIME. Regards -- Gerard
Re: [PATCH] In case of Sly, let org-babel-execute:lisp use Slynk instead of Swank
On 29.03.2023 11:42, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: The Emacs integrated development environments Slime and Sly communicate by means of similar RPC protocols with different server programs: Swank in case of Slime and Slynk in case of Sly. However, the code in org-babel-execute:lisp always expects to talk with Swank because of the hard-coded call to swank:eval-and-grab-output. After starting a Sly REPL, calls to swank:eval-and-grab-output do not talk with the Slynk server started by the Sly REPL. The attached patch "soft-codes" eval-and-grab-output to become swank:eval-and-grab-output when using Slime and slynk:eval-and-grab-output when using Sly. I do not use ob-lisp, but this patch looks reasonable. I'd appreciate if other ob-lisp users could test the patch with both SLY and SLIME. I have no comments on the Elisp part of the patch. I have a few additional remarks: The patch is against main only because it overlaps a region where bugfix and main diverged. I am willing to provide a similar patch against main. I have installed Slime and Sly with the same user-emacs-directory using package-install. Normally, both autoload when doing M-x sly, but Sly prompts you whether you want to disable Slime. I choose "yes" to test Sly. I package-delete Sly when I want to test Slime. See https://github.com/joaotavora/sly/blob/master/CONTRIBUTING.md describes in detail how Sly uses the RPC protocol. I hope that my mail reaches David (CC-ed d...@gnu.org taken from the file header), but my previous message bounced (non-existent address). Best regards -- Gerard
[PATCH] In case of Sly, let org-babel-execute:lisp use Slynk instead of Swank
Hello, The Emacs integrated development environments Slime and Sly communicate by means of similar RPC protocols with different server programs: Swank in case of Slime and Slynk in case of Sly. However, the code in org-babel-execute:lisp always expects to talk with Swank because of the hard-coded call to swank:eval-and-grab-output. After starting a Sly REPL, calls to swank:eval-and-grab-output do not talk with the Slynk server started by the Sly REPL. The attached patch "soft-codes" eval-and-grab-output to become swank:eval-and-grab-output when using Slime and slynk:eval-and-grab-output when using Sly. For more info: steps to test the patch are: 1. Open a Sly REPL with M-x sly 2. Look in the *sly-events for * ( is sbcl in my case) for slynk: prefixes 3. Type C-c C-c on the test block below 4. Look for an addition in *sly-events for * looking like (slynk:eval-and-grab-output "(let ((...)) (+ 1 1)\n)") #+name: test-ob-lisp-with-sly #+begin_src lisp -n :output results (+ 1 1) #+end_src #+RESULTS: test-ob-lisp-with-sly : 2 Best regards -- Gerard 0001-lisp-ob-lisp-fix-org-babel-execute-lisp-for-use-with.patch Description: Binary data
Re: [BUG] Emacs-29.0.60: (setopt org-babel-load-languages ...) may cause warnings
On 02.02.2023 09:26, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: May you please convert the diff into a patch with changelog entry and commit message? See https://orgmode.org/worg/org-contribute.html#org045e318 patch attached. Thanks! 1. I have assigned my copyright for Emacs stuff to the FSF Bastien, may you please confirm? 2. My initial version of the patch was against bugfix and now I have set :package-version to "9.6" Correct. You can also remove :version tag while we are at it. It is redundant when :package-version is provided (we are slowly getting rid of the :version tags across Org). according to the instructions on the org-contribute page. I do not know if this is acceptable (it feels a bit like breaking the rules), but I am happy to redo the patch for main. bugfix is fine. This is a trivial patch. I have attached an amended patch with the :version tag removed. 0001-org.el-Sync-org-babel-load-languages-with-Babel-file.patch Description: Binary data
Re: [BUG] Emacs-29.0.60: (setopt org-babel-load-languages ...) may cause warnings
Hi Igor, On 31.01.2023 11:34, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: The attached patch synchronizes the =defcustom= with the rest of the code base, groups languages by org-babel file, and uses camel-case to spell languages (the new fashion). Thanks! May you please convert the diff into a patch with changelog entry and commit message? See https://orgmode.org/worg/org-contribute.html#org045e318 patch attached. Two points: 1. I have assigned my copyright for Emacs stuff to the FSF 2. My initial version of the patch was against bugfix and now I have set :package-version to "9.6" according to the instructions on the org-contribute page. I do not know if this is acceptable (it feels a bit like breaking the rules), but I am happy to redo the patch for main. Best regards -- Gerard 0001-org.el-Sync-org-babel-load-languages-with-Babel-file.patch Description: Binary data
[BUG] Emacs-29.0.60: (setopt org-babel-load-languages ...) may cause warnings
Hi,
I have been replacing to calls to =custom-set-variables= with calls to
the safer
=setopt= (new in Emacs-29.0.60) and I discovered that calling
src_emacs-lisp{(setopt org-babel-load-languages '((eshell t) (emacs-lisp
t)))}
raises a warning because =eshell= is missing from the
=org-babel-load-languages=
=defcustom=. The code below shows that this =defcustom= is quit out of
sync with
the rest of the code base:
#+header: :wrap "src emacs-lisp :results silent :tangle no"
#+begin_src emacs-lisp :exports both :results value pp :exports both
(defun all-org-babel-execute-fns ()
"Find `ob-LANGUAGE' files in Org defining
`org-babel-execute:LANGUAGE'.
Return a list of items where the filename is the `car' of each item and
the
`cdr' of each item lists the `org-babel-execute:LANGUAGE' functions."
(let* ((dir (file-name-parent-directory (locate-library "org")))
(names (directory-files dir t (rx "ob-" (+ print) ".el"
eos
(cl-loop for name in names
for found = (has-org-babel-execute-fn name)
when found collect found)))
(defun has-org-babel-execute-fn (name)
(let* ((buffer (find-file-noselect name))
(base (file-name-base (buffer-file-name buffer)))
(regexp (rx "defun" (+ blank) "org-babel-execute:" (group (+
graphic
(matches))
(save-match-data
(save-excursion
(with-current-buffer buffer
(save-restriction
(widen)
(goto-char 1)
(while (re-search-forward regexp nil t 1)
(push (match-string-no-properties 1) matches))
(when matches
`(,base ,@matches
(all-org-babel-execute-fns)
#+end_src
#+RESULTS:
#+begin_src emacs-lisp :results silent :tangle no
(("ob-C" "C" "D" "C++" "cpp")
("ob-R" "R")
("ob-awk" "awk")
("ob-calc" "calc")
("ob-clojure" "clojurescript" "clojure")
("ob-css" "css")
("ob-ditaa" "ditaa")
("ob-dot" "dot")
("ob-emacs-lisp" "emacs-lisp")
("ob-eshell" "eshell")
("ob-forth" "forth")
("ob-fortran" "fortran")
("ob-gnuplot" "gnuplot")
("ob-groovy" "groovy")
("ob-haskell" "haskell")
("ob-java" "java")
("ob-js" "js")
("ob-julia" "julia")
("ob-latex" "latex")
("ob-lilypond" "lilypond")
("ob-lisp" "lisp")
("ob-lua" "lua")
("ob-makefile" "makefile")
("ob-maxima" "maxima")
("ob-ocaml" "ocaml")
("ob-octave" "octave" "matlab")
("ob-org" "org")
("ob-perl" "perl")
("ob-plantuml" "plantuml")
("ob-processing" "processing")
("ob-python" "python")
("ob-ruby" "ruby")
("ob-sass" "sass")
("ob-scheme" "scheme")
("ob-screen" "screen")
("ob-sed" "sed")
("ob-shell" "shell")
("ob-sql" "sql")
("ob-sqlite" "sqlite"))
#+end_src
The attached patch synchronizes the =defcustom= with the rest of the
code base, groups languages by org-babel file, and uses camel-case to
spell languages (the new fashion).
Best regards -- Gerard
fix-org-babel-load-languages.patch
Description: Binary data
[PATCH][WORG] replaces broken javascript with link
Hello, the attached patch replaces a snippet of broken javascript code with an org-mode link. Best regards -- Gerard worg-org-issues-replace-broken-javascript-with-link.patch Description: Binary data
[PATCH][WORG] Fixes broken link to worg sources
Hello, the attached patch fixes a broken link to the worg sources. Best regards -- Gerard worg-broken-link-to-worg-sources.patch Description: Binary data
Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages
On 28.11.2022 06:10, Ihor Radchenko wrote: gerard.vermeu...@posteo.net writes: disclaimers: my nationality is dutch, although I am living in France since 1987 and I don't use org-mode clocking. I have the following remarks: The real translation of "headline" into Dutch is "kop" (close to the German translation), but if "headline" should be understood like "heading" then I would recommend "rubriek" translating back in English as "column" (in a newspaper). I like "rubriek" better than "kop". Thanks! Heading is more like a section title in a document. I guess newspaper column can also fit. (btw, it is similar to Ukrainian рубрика [rubryka]) "Clock summary at" could be translated as "Klok overzicht op" in case a date follows. Yup. The date follows. It is used in the clock table title. I am attaching a patch under your name. Let me know if it fits your suggestions. The patch fits my suggestions. FYI: the word "rubriek" can also convey a classification of similar things or people (it could be used in libraries, bookkeeping of expenses or tasks).
Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages
Hello,
disclaimers: my nationality is dutch, although I am living in France
since 1987
and I don't use org-mode clocking. I have the following remarks:
The real translation of "headline" into Dutch is "kop" (close to the
German translation),
but if "headline" should be understood like "heading" then I would
recommend "rubriek"
translating back in English as "column" (in a newspaper). I like
"rubriek" better than
"kop".
"Clock summary at" could be translated as "Klok overzicht op" in case a
date follows.
Best regards -- Gerard
On 27.11.2022 01:06, Ihor Radchenko wrote:
Hi,
We have the following translations for clock table column names:
;; FIXME: translate es and nl last string "Clock summary at"
(defcustom org-clock-clocktable-language-setup
'(("en" "File" "L" "Timestamp" "Headline" "Time" "ALL"
"Total time" "File time" "Clock summary at")
("es" "Archivo" "N" "Fecha y hora" "Tarea" "Tiempo" "TODO"
"Tiempo total" "Tiempo archivo" "Clock summary at")
("fr" "Fichier" "N" "Horodatage" "En-tête" "Durée" "TOUT"
"Durée totale" "Durée fichier" "Horodatage sommaire à")
("nl" "Bestand" "N" "Tijdstip" "Hoofding" "Duur" "ALLES"
"Totale duur" "Bestandstijd" "Clock summary at")
("de" "Datei""E" "Zeitstempel" "Kopfzeile" "Dauer" "GESAMT"
"Gesamtdauer" "Dateizeit" "Erstellt am"))
"Terms used in clocktable, translated to different languages."
...)
As FIXME states, we at least need to translate "Clock summary at" to
Spanish and Dutch.
Contributions for other languages are also welcome.
P.S. I am taking this opportunity with an easy help request to see how
many people would be interested to contribute non-code.
BUG: org-lint does not agree with ox-latex and org-element-at-point
Hello, == begin of "include-myself.org" file #+caption: BUG: org-lint does not agree with ox-latex and org-element-at-point #+name: make-me-float #+include: "include-myself.org" src org :lines "1-3" == end of "include-myself.org" file == Writing the three lines between the == ... == markers to new file named "include-myself.org" and opening+exporting this file to LaTeX does what I expect: it produces a float listing the first 2 lines with a caption. The result of execution M-: org-element-at point RET with point on any of those lines looks also OK to me. However, org-lint complains that in line 3 there is a "Non-existent file argument in INCLUDE keyword". Best regards -- Gerard Package: Org mode version 9.6-pre ( @ /Users/vermeulen/.emacs.d/elpa/org-9.6pre0.20221104.24838/)
BUG: org-lint does not agree with ox-latex and org-element-at-point
Hello, == begin of "include-myself.org" file #+caption: BUG: org-lint does not agree with ox-latex and org-element-at-point #+name: make-me-float #+include: "include-myself.org" src org :lines "1-3" == end of "include-myself.org" file == Writing the three lines between the == ... == markers to new file named "include-myself.org" and opening+exporting this file to LaTeX does what I expect: it produces a float listing the first 2 lines with a caption. The result of execution M-: org-element-at point RET with point on any of those lines looks also OK to me. However, org-lint complains that in line 3 there is a "Non-existent file argument in INCLUDE keyword". Best regards -- Gerard Package: Org mode version 9.6-pre ( @ /Users/vermeulen/.emacs.d/elpa/org-9.6pre0.20221104.24838/)
Re: Export of this table fails LuaLaTeX compilation
On 12.10.2022 18:21, Max Nikulin wrote:
[...]
Stewart Thomas. [BUG] Tables with square brackets do not compile in
PDF (latex) export. Wed, 10 Nov 2021 11:16:10 -0500.
https://list.orgmode.org/cao12v+wb18nan0fudpaen94ghdt_2nbdjtc4u7n4w3hazba...@mail.gmail.com
I can not figure out an easy way to separate \\ from [b] text but to
prevent the problem you have discovered. I am unsure if
\\[0pt]
has no negative consequences and safe enough. I expect that LaTeX
sources are not easy to read when fragile sequences of tokens are
involved.
I just have realized that some users might take advantage of earlier
behavior as a feature:
- item \\
[1cm]
- item
I think that [1cm] should be treated as text, however I have no idea
how to allow users to specify amount of vertical space and to not
limit line break to LaTeX only. @@latex:\\[1cm]@@ is not suitable
when
the same text should be exported to ascii, html, etc.
[...]
Adding \relax is my fault, I did not expect that it may break \hline.
Such behavior should be stable over decades. The question is how to
allow users to have square brackets in the beginning of the line
following \\ and not break some use case.
2. On my systems ws-butler removes the trailing whitespace.
3. I edited your example with nano to add the trailing space after
\relax, but it still does not compile.
Sorry, I did not get your point with trailing space. LaTeX ignores
spaces after commands (e.g. "a\relax b" becomes "ab") and in the
beginning of the line. What I am afraid of is unintentionally
introduce white space at the beginning of the line, e.g. if
| a |
| b |
|---|
is exported as
{} a \\
{} b \\
\hline
then cell contents will be " a" and " b", not "a" and "b".
\relax a \\
\relax b \\
\hline
has no such problem.
Sorry, I have misread or misunderstood what \relax does with spaces.
Thank you for your patient explanation -- Gerard
Re: Export of this table fails LuaLaTeX compilation
On 12.10.2022 07:55, Max Nikulin wrote:
On 12/10/2022 12:15, gerard.vermeulen wrote:
On 12.10.2022 06:45, Max Nikulin wrote:
LuaLaTeX is irrelevant. It seems \hline is allowed only immediately
after \\. Minimal LaTeX example:
\begin{tabular}{l}
b\\\relax
\hline
\end{tabular}
Your example fails on my Mac texlive-2020 with:
! Misplaced \noalign.
\hline ->\noalign
{\ifnum 0=`}\fi \hrule \@height \arrayrulewidth
\futurelet...
l.40 \hline
It compiles when I remove \hline
Gerard, we forgot to post the reason why \relax has been added after
\\. The intention was to prevent errors in the case of
| a |
| [b] |
or
- item \\
[2022-10-12]
Stewart Thomas. [BUG] Tables with square brackets do not compile in
PDF (latex) export. Wed, 10 Nov 2021 11:16:10 -0500.
https://list.orgmode.org/cao12v+wb18nan0fudpaen94ghdt_2nbdjtc4u7n4w3hazba...@mail.gmail.com
I can not figure out an easy way to separate \\ from [b] text but to
prevent the problem you have discovered. I am unsure if
\\[0pt]
has no negative consequences and safe enough. I expect that LaTeX
sources are not easy to read when fragile sequences of tokens are
involved.
I just have realized that some users might take advantage of earlier
behavior as a feature:
- item \\
[1cm]
- item
I think that [1cm] should be treated as text, however I have no idea
how to allow users to specify amount of vertical space and to not
limit line break to LaTeX only. @@latex:\\[1cm]@@ is not suitable when
the same text should be exported to ascii, html, etc.
Max, thanks for the background information.
For your info:
1. I also need to remove \relax in the LaTeX export using Gentoo
texlive-2022 to compile.
2. On my systems ws-butler removes the trailing whitespace.
3. I edited your example with nano to add the trailing space after
\relax, but it still does not compile.
Re: Export of this table fails LuaLaTeX compilation
On 12.10.2022 06:45, Max Nikulin wrote:
On 12/10/2022 11:15, Ihor Radchenko wrote:
Confirmed.
But what is the problem here? Isn't \relax supposed to work in LuaTeX?
LuaLaTeX is irrelevant. It seems \hline is allowed only immediately
after \\. Minimal LaTeX example:
\begin{tabular}{l}
b\\\relax
\hline
\end{tabular}
Your example fails on my Mac texlive-2020 with:
! Misplaced \noalign.
\hline ->\noalign
{\ifnum 0=`}\fi \hrule \@height \arrayrulewidth
\futurelet...
l.40 \hline
It compiles when I remove \hline
Re: Export of this table fails LuaLaTeX compilation
On 12.10.2022 06:15, Ihor Radchenko wrote:
gerard.vermeu...@posteo.net writes:
I am regularly updating 9.6-pre from https://elpa.gnu.org/devel/ and
yesterday
my LaTeX export stopped working. The org-mode snippet below
(attached,
together
with the LaTeX export file) shows the problem. The LaTeX file
compiles
after I remove
all occurrences of \relax.
...
#+begin_src latex :exports none :results silent
\begin{center}
\begin{tabular}{l}
\hline
\colorbox{red}{\texttt{bug}}\\\relax
\colorbox{red}{\texttt{bug}}\\\relax
\hline
\end{tabular}
\end{center}
#+end_src
Confirmed.
But what is the problem here? Isn't \relax supposed to work in LuaTeX?
It does not work on my Mac with texlive-2020, so I export my org file,
open it and replace
all occurrences of \\\relax with \\ before compiling. I have to confirm
this on Gentoo Linux
with texlive-2022 at work.
I think that \\ signals the end of a table row and that \relax ends up
on the next row with
missing fields.
Export of this table fails LuaLaTeX compilation
Hello,
I am regularly updating 9.6-pre from https://elpa.gnu.org/devel/ and
yesterday
my LaTeX export stopped working. The org-mode snippet below (attached,
together
with the LaTeX export file) shows the problem. The LaTeX file compiles
after I remove
all occurrences of \relax.
Best -- Gerard
#+title: Export of this table fails LuaLaTeX compilation
#+macro: nit (eval (format "@@latex:\\colorbox{red}{\\texttt{%s}}@@"
$1))
#+options: title:nil toc:nil
Macro {{{nit(works outside table)}}} but fails inside tables where
=\\= matters. The LaTeX export fails to compile with LuaLaTeX because
of =\\\relax= instead of =\\=:
|-|
| @@latex:\colorbox{red}{\texttt{bug}}@@ |
| {{{nit(bug)}}} |
|-|
exports to:
#+begin_src latex :exports none :results silent
\begin{center}
\begin{tabular}{l}
\hline
\colorbox{red}{\texttt{bug}}\\\relax
\colorbox{red}{\texttt{bug}}\\\relax
\hline
\end{tabular}
\end{center}
#+end_src
bug.tex
Description: TeX document
bug.org
Description: Binary data
