[BUG] Can't export variable named "nil" to Texinfo
Hello,
I can export the following "Variable" to Texinfo with
`org-texinfo-export-to-texinfo':
- Variable: my-name ::
Content...
Results in the following .texi:
@defvar my-name
Content@dots{}
@end defvar
However, if the variable is named "nil" (without the quotes), the
variable name is not exported, and a warning is generated when
processing the .texi file:
- Variable: nil ::
Content...
Results in:
@defvar
Content@dots{}
@end defvar
When running `makeinfo --pdf file.texi':
file.texi:50: warning: missing category for @defvar
I saw the "Variable" to "@defvar" conversion is made with
`org-texinfo--definition-command-alist' in `ox-texinfo.el', which then
gets used in `org-texinfo--match-definition' through the
regexp. However, I was not able to see why a "nil" string isn't
processed.
signature.asc
Description: PGP signature
[BUG][PATCH] org-babel: Shared list structure causes spurious changes in user options [9.8-pre (release_9.7.10-127-g07dd3b @ /usr/local/share/emacs/site-lisp/org/)]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. This is a simplified reproducer of the problem, as discovered by user @lyndhurst on SE Emacs. See https://emacs.stackexchange.com/questions/82261/set-org-babel-source-block-parameters-dynamically for more details. Starting with `emacs -Q', open the following file: --8<---cut here---start->8--- * Bug report example #+begin_src shell echo "foo" #+end_src * Code #+begin_src elisp :results raw (setq org-babel-default-header-args:shell '((:results . "file") (:file . "results.txt") (:output-dir . "a"))) #+end_src --8<---cut here---end--->8--- Evaluate the last code block to set `org-babel-default-header-args:shell' to the indicated value, then evaluate the shell code block repeatedly: the first time it works to produce an output file `a/results.txt'; subsequent evaluations produce errors: org-ctrl-c-ctrl-c: Opening output file: No such file or directory, .../a/a/results.txt org-ctrl-c-ctrl-c: Opening output file: No such file or directory, .../a/a/a/results.txt org-ctrl-c-ctrl-c: Opening output file: No such file or directory, .../a/a/a/a/results.txt Note the increasing number of copies of the `output-dir' setting. The value of `org-babel-default-header-args:shell' is modified every time: ((:results . "file") (:file . "a/a/a/a/results.txt") (:output-dir . "a")) The problem is the way that `org-babel-get-src-block-info' constructs the `info' variable, which is used to pass around information during the evaluation: the value depends on the `org-babel-default-header-args*' variables, but is modified in place, and because of shared list structure, the modification gets propagated to the user variables. Emacs : GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.43, cairo version 1.18.0) of 2024-08-09 Package: Org mode version 9.8-pre (release_9.7.10-127-g07dd3b @/usr/local/share/emacs/site-lisp/org/) -- The following patch wraps calls to `copy-tree' around the relevant places to eliminate the sharing. >From dfe13482a8b3997aaca35063e81c7535faf02c0b Mon Sep 17 00:00:00 2001 From: Nick Dokos Date: Sat, 28 Sep 2024 15:39:25 -0400 Subject: [PATCH] org-babel: Avoid changing user options by not sharing list structure * lisp/ob-core.el (org-babel-get-src-block-info): Use `copy-tree' when using `org-babel-default-header-args*' variables to prepare the `info' variable used in src block evaluation. The `info' variable gets modified, and the modifications were affecting the values of the user variables. In particular, the `:file' setting was modified in the presence of a `:output-dir' setting, concatenating more and more copies of the directory every time the block was evaluated. Reported-by: @lyndhurst on SE Emacs Link: https://emacs.stackexchange.com/questions/82261/ --- lisp/ob-core.el | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 90c52f8b7836..e6db422c9d20 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -731,9 +731,17 @@ Otherwise, return a list with the following pattern: lang (org-babel--normalize-body datum) (apply #'org-babel-merge-params - (if inline org-babel-default-inline-header-args - org-babel-default-header-args) - (and (boundp lang-headers) (eval lang-headers t)) + ;; Use `copy-tree' to avoid creating shared structure + ;; with the `org-babel-default-header-args-*' variables: + ;; modifications by `org-babel-generate-file-param' + ;; below would modify the shared structure, thereby + ;; modifying the variables. + (copy-tree + (if inline org-babel-default-inline-header-args + org-babel-default-header-args) + t) + (and (boundp lang-headers) + (copy-tree (eval lang-headers t) t)) (append ;; If DATUM is provided, make sure we get node ;; properties applicable to its location within -- 2.46.0 -- Nick
Problems inserting accentuated dates
I have a problem some time ago. I don't know the cause: I can't insert dates accentuated, for example Saturday (in Spanish it is Sábado). If I do it, I get: <2024-09-28 s \341.> Instead of <2024-09-28 sá .> And if I try to save the buffer, the minibuffer is open with "Select coding system" message. I have no problem writing manually sáb. or sábado in the buffer, I have no coding problems. If I do M-x describe-coding-system in the buffer, I get this: Coding system for saving this buffer: U -- utf-8-unix (alias: mule-utf-8-unix cp65001-unix) Default coding system (for new files): U -- utf-8 (alias: mule-utf-8 cp65001) Coding system for keyboard input: U -- utf-8-unix (alias: mule-utf-8-unix cp65001-unix) Coding system for terminal output: U -- utf-8 (alias: mule-utf-8 cp65001) Coding system for inter-client cut and paste: U -- utf-16le-dos Defaults for subprocess I/O: decoding: U -- utf-8-dos (alias: mule-utf-8-dos cp65001-dos) encoding: U -- utf-8-unix (alias: mule-utf-8-unix cp65001-unix) Priority order for recognizing coding systems when reading files: 1. utf-8 (alias: mule-utf-8 cp65001) 2. iso-latin-1 (alias: iso-8859-1 latin-1) 3. iso-2022-7bit 4. iso-2022-7bit-lock (alias: iso-2022-int-1) 5. iso-2022-8bit-ss2 6. emacs-mule 7. raw-text 8. iso-2022-jp (alias: junet) 9. in-is13194-devanagari (alias: devanagari) 10. chinese-iso-8bit (alias: cn-gb-2312 euc-china euc-cn cn-gb gb2312) 11. utf-8-auto 12. utf-8-with-signature 13. utf-16 14. utf-16be-with-signature (alias: utf-16-be) 15. utf-16le-with-signature (alias: utf-16-le) 16. utf-16be 17. utf-16le 18. japanese-shift-jis (alias: shift_jis sjis) 19. chinese-big5 (alias: big5 cn-big5 cp950) 20. undecided I have not that problem in emacs -Q GNU Emacs 29.3 (build 2, x86_64-w64-mingw32) of 2024-03-24 Org mode version 9.8-pre
Documentation and examples about using Org mode to write content for a static web-site
Hello, I had published my open source scripts and documentation about creating and maintaining static, tree like web-sites under https://web222.webclient5.de/prj/content/trgensit You can now download a second ZIP file "trgensit-org.zip" from that page. This new ZIP file additionally contains the /Org mode source files/ of the documentation. I have added a documentation page that describes how I use Org mode in this context. The documentation also serves as an example for a web-site. Please note that this is not about using Org publishing functionality. It is rather about just using Org mark-up and the Org mode HTML exporter to write core page content. Best regards Thomas -- Thomas Redelberger rede...@gmx.de
Re: Documentation and examples about using Org mode to write content for a static web-site
Hi Thomas, Thanks for sharing how you do your stuff related to static website generation. When I see things like this, it comes to me this expression: I love this community!! By the way, on the page, this link is incorrect: > you might want to download the extended ZIP file trgensit-org.zip it should be https://web222.webclient5.de/prj/content/trgensit/trgensit-org.zip Cheers, pinmacs OpenPGP_0x9D64597C3A982DCA.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
[BUG] org-babel-header-arg-expand is rather cavalier about "appropriate context" [9.8-pre (release_9.7.10-127-g07dd3b @ /usr/local/share/emacs/site-lisp/org/)]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. This was reported by user @Addlai on Emacs SE. See https://emacs.stackexchange.com/questions/82276/stop-org-cycle-from-prompting-for-header-args `org-babel-header-arg-expand' is added to the hook `org-cycle-tab-first-hook' so when a TAB is pressed, the function is called to check whether the context is approrpiate to call `org-babel-enter-header-arg-w-completion'. But the only thing it checks is whether the preceding character is a colon and whether we are in a source block (by calling `org-babel-where-is src-block-head'), so if one presses TAB inside a python source block after a colon, the context is deemed "appropriate" and you are asked for a header arg. It should probably check that it's *on* the header line of the source block, not just that it is *inside* the header block. Emacs : GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.43, cairo version 1.18.0) of 2024-08-09 Package: Org mode version 9.8-pre (release_9.7.10-127-g07dd3b @ /usr/local/share/emacs/site-lisp/org/) -- Nick
