Re: [PATCH] initialize org-babel-tangle-lang-exts to nil

2024-06-28 Thread Tom Gillespie
> More accurate approach would be using (eval-after-load 'ob-tangle > ...). This is what is being done in WIP branch that addresses many > similar problems across Org mode: > https://git.sr.ht/~yantar92/org-mode/log/feature/refactor-deps-v2 > https://git.sr.ht/~yantar92/org-mode/commit/6bcb99413e18

Re: [PATCH] initialize org-babel-tangle-lang-exts to nil

2024-06-28 Thread Ihor Radchenko
Tom Gillespie writes: >Here is a fix for bad init values for org-babel-tangle-lang-exts. > Details in the patch commit message. > ... > Subject: [PATCH] initialize org-babel-tangle-lang-exts to nil > ... > org-bable-tangle-lang-exts should be initialized to nil and not as a > void variable, i

[BUG] Unexpected behaviour of TAB in table depending on font family [9.6.15 (release_9.6.15 @ /snap/emacs/current/usr/share/emacs/29.4/lisp/org/)]

2024-06-28 Thread Giovanni Pavolini
--text follows this line-- 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. --

[PATCH] initialize org-babel-tangle-lang-exts to nil

2024-06-28 Thread Tom Gillespie
Hi, Here is a fix for bad init values for org-babel-tangle-lang-exts. Details in the patch commit message. Best, Tom From 71558cc80181b5d7a1d720785165b358984284e3 Mon Sep 17 00:00:00 2001 From: Tom Gillespie Date: Fri, 28 Jun 2024 14:08:08 -0700 Subject: [PATCH] initialize org-babel-tangle-lang

Re: [POLL] We plan to remove #+LINK: ...%(my-function) placeholder from link abbreviation spec

2024-06-28 Thread Steven Allen
Suhail Singh writes: > Steven Allen writes: > >> The concern is that, e.g., there may b a function _marked_ as pure >> that's not actually pure, leaks some information, and/or has a >> security vulnerability (e.g., a C function exposed to lisp that's >> marked as pure but internally has, e.g., a

Re: [POLL] We plan to remove #+LINK: ...%(my-function) placeholder from link abbreviation spec

2024-06-28 Thread Suhail Singh
Steven Allen writes: > The concern is that, e.g., there may b a function _marked_ as pure > that's not actually pure, leaks some information, and/or has a > security vulnerability (e.g., a C function exposed to lisp that's > marked as pure but internally has, e.g., a buffer overflow). Are there

Re: Org Babel "swallows" table column groups

2024-06-28 Thread S. Sajad Hosseini Balef
From mboxrd@z Thu Jan  1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:58f0::])     (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))     by ms13.migadu.com with LMTPS     id QIBcKZmwfmY+JwAAe85BDQ:P1     (envelope-from )     for ; Fri, 28 Jun 2024 12:46

Re: [POLL] We plan to remove #+LINK: ...%(my-function) placeholder from link abbreviation spec

2024-06-28 Thread Suhail Singh
Ihor Radchenko writes: > Yup. I only meant %(...) placeholder constructs. ("linkkey" > . REPLACE) where REPLACE is a function symbol will still be allowed. Thank you for confirming. Please ignore my previous response. -- Suhail

Re: [POLL] We plan to remove #+LINK: ...%(my-function) placeholder from link abbreviation spec

2024-06-28 Thread Steven Allen
Suhail Singh writes: > Steven Allen writes: > >> 1. While this feature no longer invokes completely arbitrary code, it >> still allows an attacker to call any function marked as "pure" which >> is a pretty large attack surface. > > I am struggling to assess this, because it's not clear to me wha

Re: [POLL] We plan to remove #+LINK: ...%(my-function) placeholder from link abbreviation spec

2024-06-28 Thread Ihor Radchenko
Suhail Singh writes: >> You can, of course, write that function; but then you might as well >> use org-link-abbrev-alist instead of defining a local #+LINK. > > Perhaps I misunderstood, I thought the thing being polled was whether or > not to allow org-link-abbrev-alist to have REPLACE (per its d

Re: [POLL] We plan to remove #+LINK: ...%(my-function) placeholder from link abbreviation spec

2024-06-28 Thread Suhail Singh
Steven Allen writes: > 1. While this feature no longer invokes completely arbitrary code, it > still allows an attacker to call any function marked as "pure" which > is a pretty large attack surface. I am struggling to assess this, because it's not clear to me what the threat model is. Could yo

Re: [POLL] We plan to remove #+LINK: ...%(my-function) placeholder from link abbreviation spec

2024-06-28 Thread Steven Allen
Suhail Singh writes: > Ihor Radchenko writes: > >> If you are actively using #+LINK: keywords with %(...) placeholders or >> have any objections to this feature removal, please let us know. > > I do not actively use this feature, however, removing it seems > excessive. IIUC, it's a useful feat

Re: [POLL] Bug of Feature? Attack vector via deceiving link abbrevs

2024-06-28 Thread Suhail Singh
Ihor Radchenko writes: > On the other hand, I can totally see people making use of the current > behavior to have custom filters for existing link types. Yes, I use this currently for redirecting reddit links. It's certainly a feature in my opinion. -- Suhail

Re: [POLL] Bug of Feature? Attack vector via deceiving link abbrevs (was: [ANN] Emergency bugfix release: Org mode 9.7.5)

2024-06-28 Thread Steven Allen
Ihor Radchenko writes: > Ihor Radchenko writes: > >> I just released Org mode 9.7.5 that fixes a critical vulnerability. >> The release is coordinated with emergency Emacs 29.4 release. > > This one is another potential issue (or a feature) we have found while > discussing the main vulnerability

Re: [POLL] We plan to remove #+LINK: ...%(my-function) placeholder from link abbreviation spec

2024-06-28 Thread Suhail Singh
Ihor Radchenko writes: > If you are actively using #+LINK: keywords with %(...) placeholders or > have any objections to this feature removal, please let us know. I do not actively use this feature, however, removing it seems excessive. IIUC, it's a useful feature in situations when the tag may

Re: Please document the caching and its user options

2024-06-28 Thread Ihor Radchenko
Rudolf Adamkovič writes: > Ihor Radchenko writes: > >> Fixed, on bugfix. >> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5ffb2675f > > FYI: A typo, 's/has/hash/'. > > (Optionally, also 's/anyway //'.) Thanks! Fixed https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?

Re: Org Babel "swallows" table column groups

2024-06-28 Thread Ihor Radchenko
Rudolf Adamkovič writes: > Given the source block > > #+BEGIN_SRC emacs-lisp > (list (list 1 2) (list "/" "<>") 'hline (list 3 4) (list 5 6)) > #+END_SRC > > Org Babel outputs > ... > with the second element of the list > > (list "/" "<>") > > swallowed, without a word. > > Why would Org

[POLL] Bug of Feature? Attack vector via deceiving link abbrevs (was: [ANN] Emergency bugfix release: Org mode 9.7.5)

2024-06-28 Thread Ihor Radchenko
Ihor Radchenko writes: > I just released Org mode 9.7.5 that fixes a critical vulnerability. > The release is coordinated with emergency Emacs 29.4 release. This one is another potential issue (or a feature) we have found while discussing the main vulnerability. Currently, one can create an Org

Re: [POLL] ob-R, ob-julia: Should we force-disable ess-ask-for-ess-directory?

2024-06-28 Thread Suhail Singh
Ihor Radchenko writes: > I'd like to hear from ob-R/ob-julia users whether the current behavior > is something they rely on. It's a (minor) nuisance, but one I'd be happy to have fixed. -- Suhail

[POLL] We plan to remove #+LINK: ...%(my-function) placeholder from link abbreviation spec (was: [ANN] Emergency bugfix release: Org mode 9.7.5)

2024-06-28 Thread Ihor Radchenko
Dear all, > I just released Org mode 9.7.5 that fixes a critical vulnerability. > The release is coordinated with emergency Emacs 29.4 release. > ... > The vulnerability involves arbitrary Shell code evaluation... In a view of the recent vulnerability, we are considering to remove the offending f

Re: [POLL] ob-R, ob-julia: Should we force-disable ess-ask-for-ess-directory? (was: [BUG] Relative filenames for graphics output in ob-R.el [9.8-pre (release_9.7.4-80-g7fa169)])

2024-06-28 Thread Christian Moe
Rudolf Adamkovič writes: > Ihor Radchenko writes: > >> I'd like to hear from ob-R/ob-julia users whether the current behavior >> is something they rely on. If not, I'd prefer to follow the conventions >> we introduce in the manual and suppress the ESS's directory prompt. > > +1 from me; I have

Re: 'org-latex-export-to-latex' consistently failing under org 9.7.5

2024-06-28 Thread Ihor Radchenko
Sharon Kimble writes: > I've tried my command on another project, and it works there, so I've > gone back to the problematic file/project and then started splitting > with the first chapter now working using my latex export command, > and I gradually built it again till I've found where the

Re: Please document the caching and its user options

2024-06-28 Thread Rudolf Adamkovič
Ihor Radchenko writes: > Fixed, on bugfix. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5ffb2675f FYI: A typo, 's/has/hash/'. (Optionally, also 's/anyway //'.) Rudy -- "The whole science is nothing more than a refinement of everyday thinking." --- Albert Einstein, 1879-1

Re: [POLL] ob-R, ob-julia: Should we force-disable ess-ask-for-ess-directory? (was: [BUG] Relative filenames for graphics output in ob-R.el [9.8-pre (release_9.7.4-80-g7fa169)])

2024-06-28 Thread Rudolf Adamkovič
Ihor Radchenko writes: > I'd like to hear from ob-R/ob-julia users whether the current behavior > is something they rely on. If not, I'd prefer to follow the conventions > we introduce in the manual and suppress the ESS's directory prompt. +1 from me; I have always found that ESS prompt annoying

Org Babel "swallows" table column groups

2024-06-28 Thread Rudolf Adamkovič
Given the source block #+BEGIN_SRC emacs-lisp (list (list 1 2) (list "/" "<>") 'hline (list 3 4) (list 5 6)) #+END_SRC Org Babel outputs #+RESULTS: | 1 | 2 | |---+---| | 3 | 4 | | 5 | 6 | with the second element of the list (list "/" "<>") swallowed, without a word. Why wou

Re: 'org-latex-export-to-latex' consistently failing under org 9.7.5

2024-06-28 Thread Sharon Kimble
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Ihor Radchenko writes: > Sharon Kimble writes: > >> Has exporting to latex changed in 'org 9.7.5' please? >> >> I'm using this to export to latex - >> = >> (global-set-key (kbd "s-#") 'org-latex-export-to-latex) >> = >> >> And now its

Re: [BUG] test [9.5.2 (release_9.5.2-303-gb7cba6 @ /usr/share/emacs/site-lisp/org/)]

2024-06-28 Thread Ihor Radchenko
purity.pi...@tuta.io writes: > it appears that with the latest version from melpa the error does not appear > anymore > sorry! Thanks for the update! Canceled. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at