Re: [PATCH] before emit an error message, try to load the babel language
Hi Ihor, I use the `setopt` in my dot-emacs now, and won't make code changes. Please feel free to close this ticket, and any code change to enhance the discussed issue is welcome. Thanks
Re: [PATCH] before emit an error message, try to load the babel language
Thank you all for the comments, and agree with no code change. Please feel free to close this ticket. Thanks
Re: [PATCH] before emit an error message, try to load the babel language
Hi Ihor, Thanks for the comment. If we switch to the `add-variable-watcher', it seems we'll load the ob-LANG in the callback immediately. The previous change can lazyly load the babel languages until the user tries to evaluate the source block.
Re: [PATCH] before emit an error message, try to load the babel language
On Sat, Apr 22, 2023 at 12:42 PM Ihor Radchenko wrote: > the cleanest way will be using `add-variable-watcher'. Hi Ihor, The "add-variable-watcher" may not be able to deal with the local/global variable `org-babel-load-languages' correctly. On Sat, Apr 22, 2023 at 8:33 AM Ruijie Yu wrote: > Instead of that, I think you should have some sort of conditional in the > `unless' condition. Something like: > --8<---cut here---start->8--- > (unless (or (fboundp cmd) > (ignore (and (alist-get lang org-babel-load-languages) > (require (intern (concat "ob-" lang) > (fboundp cmd)) > (error "... %s" lang)) > --8<---cut here---end--->8--- The logic in the patch will follow the function `org-babel-do-load-languages' to load the ob-LANG without capturing the error. I changed the patch to follow your comments. Please review the new patch I attached. Thanks. From acc72f9f42120d07cc728eeebb9dd976b4568c1f Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Sat, 22 Apr 2023 00:00:39 + Subject: [PATCH] *lisp/ob-core.el: load lang in (org-babel-execute-src-block) --- lisp/ob-core.el | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 471887a3a..0fc4cbe9f 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -714,6 +714,8 @@ a list with the following pattern: (defvar *this*) ; Dynamically bound in `org-babel-execute-src-block' ; and `org-babel-read' +(defvar org-babel-load-languages) + ;;;###autoload (defun org-babel-execute-src-block ( arg info params executor-type) "Execute the current source code block and return the result. @@ -794,7 +796,9 @@ guess will be made." d (cmd (intern (concat "org-babel-execute:" lang))) result exec-start-time) - (unless (fboundp cmd) + (unless (or (fboundp cmd) + (and (alist-get (intern lang) org-babel-load-languages) + (require (intern (concat "ob-" lang)) nil t))) (error "No org-babel-execute function for %s!" lang)) (message "Executing %s %s %s..." (capitalize lang) @@ -1952,8 +1956,6 @@ With optional prefix argument ARG, jump backward ARG many source blocks." (interactive "p") (org-previous-block arg org-babel-src-block-regexp)) -(defvar org-babel-load-languages) - ;;;###autoload (defun org-babel-mark-block () "Mark current source block." -- 2.20.5
[PATCH] before emit an error message, try to load the babel language
Hi, The function `org-babel-execute-src-block' will emit an error message if the language is not loaded. Before the error message, the patch will give a try to load the associated babel language. Why does the language exist in the `lang org-babel-load-languages' but not be loaded? Because the `org-babel-load-languages' are defined as a customer variable with :set 'org-babel-do-load-languages, the ":set" function can only be triggered with function `custom-set-variables`. While setq/cl-pushnew `org-babel-load-languages' won't trigger the `:set' function, then the error message will be displayed if I run the code in the org file. Please help review that patch. Thanks. Regards From 39a15a34bdb8bd0c397fbd80cdfb0723ce229066 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Sat, 22 Apr 2023 00:00:39 + Subject: [PATCH] *lisp/ob-core.el: load lang in (org-babel-execute-src-block) --- lisp/ob-core.el | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 471887a3a..2ed4f6b5b 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -795,7 +795,9 @@ guess will be made." (cmd (intern (concat "org-babel-execute:" lang))) result exec-start-time) (unless (fboundp cmd) - (error "No org-babel-execute function for %s!" lang)) + (if (alist-get lang org-babel-load-languages) + (require (intern (concat "ob-" lang))) +(error "No org-babel-execute function for %s!" lang))) (message "Executing %s %s %s..." (capitalize lang) (pcase executor-type -- 2.20.5
Re: [BUG] dead loop on (org-table-clean-line "|a|b|") [9.6 (release_9.6-3-ga4d38e @ share/emacs/29.0.60/lisp/org/)]
Hi Ihor, > Considering that you can only reproduce with Spacemacs, it might be > spacemacs screwing the match data. Not Org. > There is no reason to fix something not caused by Org on Org side. Agree with you, I had located the dead loop is cause by the advice function for set-window-buffer from evil package, in which the function will screw the match data. I had posted a patch to the evil-package to fix this issue. https://github.com/emacs-evil/evil/pull/1724/files Please mark this ticket as closed if you wish. Thank you Lin
Re: [BUG] dead loop on (org-table-clean-line "|a|b|") [9.6 (release_9.6-3-ga4d38e @ share/emacs/29.0.60/lisp/org/)]
Hi Ihor, > I cannot reproduce. > Can you please provide detailed steps starting from emacs -Q? The bug caused by the function org-table-clean-line calls the org-string-width inside a string-match clause without protection, for the org-string-width maybe change the match data then cause the string-match run into wrong result. The attachment is a quick patch for the issue, please help to review and apply it, thanks From 428f989c6e9f846cf6a1bbb25ada56146789a2c6 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Fri, 2 Dec 2022 07:31:05 + Subject: [PATCH] org-table.el: fix match-data changed in org-table-clean-line --- lisp/org-table.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-table.el b/lisp/org-table.el index b160dc97c..6e6835fba 100644 --- a/lisp/org-table.el +++ b/lisp/org-table.el @@ -1699,7 +1699,7 @@ In particular, this does handle wide and invisible characters." (setq s (mapconcat (lambda (x) (if (member x '(?| ?+)) "|" " ")) s "")) (while (string-match "|\\([ \t]*?[^ \t\r\n|][^\r\n|]*\\)|" s) (setq s (replace-match - (concat "|" (make-string (org-string-width (match-string 1 s)) + (concat "|" (make-string (save-match-data (org-string-width (match-string 1 s))) ?\ ) "|") t t s))) s)) -- 2.20.5
Re: [BUG] dead loop on (org-table-clean-line "|a|b|") [9.6 (release_9.6-3-ga4d38e @ share/emacs/29.0.60/lisp/org/)]
Hi Ihor, > I cannot reproduce. > Can you please provide detailed steps starting from emacs -Q? It's not happened with emacs -Q, but happened with Spacemace configuration.
[BUG] dead loop on (org-table-clean-line "|a|b|") [9.6 (release_9.6-3-ga4d38e @ share/emacs/29.0.60/lisp/org/)]
Hi, The emacs builtin org-mode will stuck after try to expand the table with Tab on a table column. After investigate, I found the function org-table-clean-line will run into dead loop for a simply call: (org-table-clean-line "|a|b|") Please help to fix this function. Thanks. Best, Lin
Re: Subject: [PATCH] Fix DISPLAY error on exporting org with plantuml to html
Hi lhor, You're totally right, the commit b5f0efc had appended the `-headless` to the jar parameter list. Here is the comment: > *** =org-plantump-executable-args= is renamed and applies to jar as well The original issue does not exist now. Please ignore the previous patch. Thank you so much. B.R. Lin
Re: *doc/org-manual.org: Fix the description for "Internal Link" in the org-mode manual
Hi Ihor, Clear! Thank you so much! Please just ignore this patch, and close this ticket. B.R. Lin
Re: *doc/org-manual.org: Fix the description for "Internal Link" in the org-mode manual
Hi Ihor, Thank you for the investigation, verify insight, I'll avoid this snapshot from my org files. And changing the "CAPTION" to "PROPERTY" in the foot script, is it correctly? Thanks B.R. Lin
*doc/org-manual.org: Fix the description for "Internal Link" in the org-mode manual
Hi,
When I try to export follow org document to html, there is an error message:
Unable to resolve link: "Test".
The foot script in section "Internal Link" of org-mode manual says:
> When targeting a ‘NAME’ keyword, the ‘CAPTION’ keyword is mandatory in order
> to get proper numbering
Adding a CAPTION not work, but adding the 'PROPERTY' before name does work.
So the attached patch try to correct the description in the foot script.
#+begin_src python :results table
return 1
#+end_src
#+PROPERTY:
#+NAME: Test
#+RESULTS:
|1|
[[Test]]
From 9b473024a5f1e19e00f198d97b1be13789062c82 Mon Sep 17 00:00:00 2001
From: Lin Sun
Date: Wed, 1 Jun 2022 00:01:07 +
Subject: [PATCH] manual: Fix the internal-link document for it depends on the
PROPERTY
* doc/org-manual.org: The internal-link acctually depends on PROPERTY
than CAPTION
---
doc/org-manual.org | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 9094f81..a2c9df2 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -21922,8 +21922,8 @@ can be used. Just type a star followed by a few optional letters into
the buffer and press {{{kbd(M-TAB)}}}. All headlines in the current
buffer are offered as completions.
-[fn:26] When targeting a =NAME= keyword, the =CAPTION= keyword is
-mandatory in order to get proper numbering (see [[*Captions]]).
+[fn:26] When targeting a =NAME= keyword, the =PROPERTY= keyword is
+mandatory in order to get proper numbering (see [[*Property Syntax]]).
[fn:27] The actual behavior of the search depends on the value of the
variable ~org-link-search-must-match-exact-headline~. If its value is
--
2.7.0
