Re: Seemingly inconsistent whitespace ownership

[Tom Alexander]

On August 11, 2023 5:20:08 AM EDT, Ihor Radchenko  wrote:
>"Tom Alexander"  writes:
>
>> The org-mode documentation states: "With the exception of list items, blank 
>> lines belong to the preceding element with the narrowest possible scope. For 
>> example, if at the end of a section we have a paragraph and a blank line, 
>> that blank line is considered part of the paragraph."
>>
>> https://orgmode.org/worg/org-syntax.html#org9bc833d
>>
>> So I created a test org-mode document with exactly that scenario described:
>> ...
>> and then I ran a M-x eval-expression (message "%s" (pp-to-string 
>> (org-element-parse-buffer))) to see the parse tree. I'll paste the output at 
>> the end because its a wall of text, but analyzing it:
>> ...
>> Its only child is a paragraph which has a :begin at 1 and :end at 10, which 
>> only includes the line break at the end of "foo bar." but this is exactly 
>> the scenario described in the documentation (a paragraph at the end of a 
>> section) so I would expect the paragraph to end at 14, not 10.
>
>You are right and you revealed an existing inconsistency between our
>incremental and recursive parsers (org-element-parse-buffer is the
>recursive parser).
>
>Fixed, on main.
>https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=bfe1179dc
>
>Also, in addition to list items, footnote-definitions do not extend
>their contents to the trailing blank lines.
>I now clarified it in org-syntax document.
>https://git.sr.ht/~bzg/worg/commit/3e91f5be
>
>-- 
>Ihor Radchenko // yantar92,
>Org mode contributor,
>Learn more about Org mode at .
>Support Org development at ,
>or support my work at 

Oh neat, I didn't know there were two! I'll check that out. Thanks!

Re: Or probably just fix the org-ctags hook functions?

[Jens Schmidt]

On 2023-08-11  23:48, Ihor Radchenko wrote:


- If you run into this issue, the real pain is to understand what's
going on, since org-ctags might get loaded in surprising ways.  So
probably we should make that easier.


The quick fix is unsetting `help-enable-completion-autoload'.


Unfortunately, that isn't easy to understand, either.


And I do not think that we should be in rush pushing workarounds -
org-ctags has been around for a long time in its existing state.
I'd prefer to first figure out the general policy for such situations.


Right, but even though org-ctags has been stable, something else *has*
changed that let's this issue pop up now.  For Nick it seems to be the
Emacs version, for me I'm pretty sure the recent upgrade from Org 9.5 to
9.6 in Debian testing, with Emacs unchanged on version 28.

Anyway, probably let's just wait whether more complaints on that will
come in.

Re: Or probably just fix the org-ctags hook functions?

[Ihor Radchenko]

Jens Schmidt  writes:

> - If you run into this issue, the real pain is to understand what's
>going on, since org-ctags might get loaded in surprising ways.  So
>probably we should make that easier.

The quick fix is unsetting `help-enable-completion-autoload'.

And I do not think that we should be in rush pushing workarounds -
org-ctags has been around for a long time in its existing state.
I'd prefer to first figure out the general policy for such situations.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Or probably just fix the org-ctags hook functions?

[Jens Schmidt]

On 2023-08-11  19:01, Nick Dokos wrote:


Sure, but we should not reject Jens' proposal just because of this
argument. We can use the suggestions to improve org-ctags itself, after
it is explicitly loaded.


Absolutely.

My disagreement was only with the part that I quoted, in particular
the "Probably the problem is not the side-effects done by loading
=org-ctags= ..."  part: from my POV, that is *exactly* the problem
which I would like to see addressed.


I was trying to provide some facts that could help deciding on this.
And to find some compromise here that would fit all users and sizes.
More notes and another compromise:

- The general discussion in that other branch about all Org libraries,
  ever, is IMO of general interest but doesn't help users that run into
  this issue in short term.  I'd focus on this single library instead to
  get a fix soon, and not only in main.

- I understand both "no-breaking-changes" and "no-side-effects"
  positions.  Personally, I'd even tend to the "no-side-effects"
  position.

- If you run into this issue, the real pain is to understand what's
  going on, since org-ctags might get loaded in surprising ways.  So
  probably we should make that easier.

How about *not* using the current functions

  `org-ctags-find-tag'
  `org-ctags-ask-rebuild-tags-file-then-find-tag'
  `org-ctags-ask-append-topic'

as default value for `org-ctags-open-link-functions', but rather only
function

  `org-ctags-warn-about-enabling-ctags'

defined as follows:

  (defun org-ctags-warn-about-enabling-ctags ( _)
(warn "You enabled (on purpose or by accident) org-ctags.

  If that was not your intention, or if you really only want to open links
  as you always have been used to, use customize to disable function
  `org-ctags-warn-about-enabling-ctags' in variable
  `org-ctags-open-link-functions'.

  Otherwise, you might want to use customize to disable function
  `org-ctags-warn-about-enabling-ctags' in `org-ctags-open-link-functions'
  and instead enable the previous default functions `org-ctags-find-tag',
  `org-ctags-ask-rebuild-tags-file-then-find-tag', and
  `org-ctags-ask-append-topic'.

  Note that in a future Org version automatic enabling of org-ctags might
  be obsoleted, so consider explicitly enabling it by adding

(require 'org-ctags)
(org-ctags-enable)

  to your Emacs initialization file if you actually want to use it.")
(remove-hook 'org-open-link-functions
 #'org-ctags-warn-about-enabling-ctags))

The last line would take care about getting this warning at most once
per Emacs session.

In addition redefine function `org-ctags-enable' to add a test on
`org-ctags-open-link-functions' as follows:

  (defun org-ctags-enable ()
(when org-ctags-open-link-functions
  (put 'org-mode 'find-tag-default-function 
'org-ctags-find-tag-at-point)

  (setq org-ctags-enabled-p t)
  (dolist (fn org-ctags-open-link-functions)
(add-hook 'org-open-link-functions fn t

which makes library loading free of side-effect if variable
org-ctags-open-link-functions equals nil.

That way:

- Users who previously have customized the variable are not affected at
  all by the change.

- All others understand better what's going on and can decide either
  way.  If they decide against org-ctags, and customize the variable
  accordingly, they will have no side-effects from org-ctags in the
  future.

- Any future general solution could resolve this in a more beautiful
  and, um, general way.

Re: [patch] ox-latex.el: fix blank lines behavior in verse block

[Juan Manuel Macías]

Ihor Radchenko writes:

> Juan Manuel Macías  writes:
>
>> ... In any case, the fact that the verse block can also be used to
>> literally export line breaks and horizontal/vertical spaces is
>> interesting. Something occurred to me that I don't know if it's a bit
>> foolhardy: how about a LaTeX attribute ':literal t'? If used, it would
>> not export to a verse environment (specialized in poetry) but to normal
>> text, without environment, but with line breaks and horizontal and
>> vertical spacing preserved... wdyt?
>
> If one uses verse blocks to export to multiple backends, your suggestion
> sounds reasonable. That way, export results will look closer across
> different export backends.

How about this (pre-)patch? With the `:literal' attr., the content of the
block is exported "as is", with all manual formatting preserved.

I have made some modifications in the horizontal and vertical spaces (in
case :literal is used), because the em does not seem the correct length
to me. The em equals the font size in points, and, vertically, it would
not equal a blank line (line spacing is usually 120% of the em), so it's
safest to use \baselineskip. Thus, \vspace*{\baselineskip} is identical
to leaving an empty line. As for the horizontal space, the em is greater
than the normal space. The closest thing would be to use
\fontdimen2\font. So, if one puts 6 manual spaces (with the spacebar
key), it is exported as \hspace*{6\fontdimen2\font}

-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com
>From baf9cc50313bb7df94e8173349db9c834f1ccf64 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Fri, 11 Aug 2023 19:57:49 +0200
Subject: [PATCH] lisp/ox-latex.el: add the `:literal' attribute to verse
 block.

* (org-latex-verse-block): now the treatment of blank lines is
consistent with the syntax of the LaTeX `verse' environment, and the
one provided by the `verse' package. If the `':literal attribute is
used, the content is not exported within a `verse' environment, but as-is,
preserving horizontal spaces, line breaks, and blank lines.
---
 lisp/ox-latex.el | 52 
 1 file changed, 39 insertions(+), 13 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 31cad1dc4..557ceee1b 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -4116,32 +4116,58 @@ contextual information."
   (let* ((lin (org-export-read-attribute :attr_latex verse-block :lines))
  (latcode (org-export-read-attribute :attr_latex verse-block :latexcode))
  (cent (org-export-read-attribute :attr_latex verse-block :center))
- (attr (concat
-	(if cent "[\\versewidth]" "")
-	(if lin (format "\n\\poemlines{%s}" lin) "")
-	(if latcode (format "\n%s" latcode) "")))
+ (lit (org-export-read-attribute :attr_latex verse-block :literal))
+ (attr (if (not lit)
+		   (concat
+		(if cent "[\\versewidth]" "")
+		(if lin (format "\n\\poemlines{%s}" lin) "")
+		(if latcode (format "\n%s" latcode) ""))
+		 ""))
  (versewidth (org-export-read-attribute :attr_latex verse-block :versewidth))
- (vwidth (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) ""))
- (linreset (if lin "\n\\poemlines{0}" "")))
+ (vwidth (if (not lit)
+		 (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) "")
+		   ""))
+ (linreset (if (not lit)
+		   (if lin "\n\\poemlines{0}" "")
+		 "")))
 (concat
  (org-latex--wrap-label
   verse-block
   ;; In a verse environment, add a line break to each newline
   ;; character and change each white space at beginning of a line
-  ;; into a space of 1 em.  Also change each blank line with
-  ;; a vertical space of 1 em.
-  (format "%s\\begin{verse}%s\n%s\\end{verse}%s"
+  ;; into a normal space, calculated with `\fontdimen2\font'.
+  ;; One or more blank lines between lines are exported as a
+  ;; single blank line.  If the `:literal' attribute is used,
+  ;; CONTENTS is exported as is, with no environment, preserving
+  ;; line breaks and vertical and horizontal spaces.
+  (format (if (not lit)
+		  "%s\\begin{verse}%s\n%s\\end{verse}%s"
+		"%s%s\n%s%s")
 	  vwidth
 	  attr
 	  (replace-regexp-in-string
-	   "^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
+	   "^[ \t]+" (lambda (m) (format "\\hspace*{%d\\fontdimen2\\font}" (length m)))
 	   (replace-regexp-in-string
-(concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$")
-	"\\vspace*{1em}"
+(if (not lit)
+		(concat "\\("
+			(regexp-quote org-latex-line-break-safe)
+			"\n\\)"
+			"\\(^[ \t]*"
+			(regexp-quote org-latex-line-break-safe)
+			"\n"
+			"\\)+")
+		  (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$"))
+	(if 

Re: Or probably just fix the org-ctags hook functions?

[Nick Dokos]

Ihor Radchenko  writes:

> Nick Dokos  writes:
>
>>> ...
>>> Probably the problem is not the side-effects done by loading
>>> =org-ctags=, but rather that these hook function from =org-ctags= try
>>> to do their job when the environment is not really ready for them,
>>> i.e. when there is no known tag file around.
>>> ...
>>
>> I disagree: the changes are done behind my back in an (almost)
>> invisible manner and leave me surprised and mystified. Even if there
>> was a TAGS file around, having links behave differently from one
>> moment to the next, when the only thing I did in-between was ask for
>> help on a completely unrelated Org mode function, is a nasty surprise.
>
> Sure, but we should not reject Jens' proposal just because of this
> argument. We can use the suggestions to improve org-ctags itself, after
> it is explicitly loaded.

Absolutely.

My disagreement was only with the part that I quoted, in particular
the "Probably the problem is not the side-effects done by loading
=org-ctags= ..."  part: from my POV, that is *exactly* the problem
which I would like to see addressed.

-- 
Nick

Re: [SUMMARY] [[bbb:OrgMeetup]] on Wed, Aug 9, 19:00 UTC+3 (was: Interest in an Org video meetup?)

[William Denton]

On 10 August 2023, Ihor Radchenko wrote:


Thanks everyone who participated! We had quite a few people by Emacs
meetup standards.


Thanks for organizing this!  It was a good session, and I picked up a few tips 
and things to try out.  Seeing the Arabic dissertation was a highlight.  It was 
also interesting seeing how others make great use of some parts of Org I use 
very little.  And of course just seeing what someone else's Emacs looks like is 
always fun.


(For those who weren't there:  No one had their camera on, it was screen-sharing 
and people talking.)


Bill

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada
CO₂: 421.30 ppm (Mauna Loa Observatory, 2023-08-10)

Re: [PATCH] org-macs.el: Fix Emacs-26 compatibility

[Ihor Radchenko]

Max Nikulin  writes:

> Current state of the main branch is not compatible with Emacs-26.
>
> Loading /home/ubuntu/src/org-mode/lisp/org-compat.el (source)...
> Eager macro-expansion failure: (wrong-number-of-arguments (2 . 2) 6)
>
> It is again `setq-local' call with multiple variables. See the attached 
> patch that splits it into several parts.

Thanks!
Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2f79c63c2

That failure does not really point to where it happened... I am
wondering how you managed to find out the cause.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

[PATCH] org-macs.el: Fix Emacs-26 compatibility

[Max Nikulin]

Current state of the main branch is not compatible with Emacs-26.

Loading /home/ubuntu/src/org-mode/lisp/org-compat.el (source)...
Eager macro-expansion failure: (wrong-number-of-arguments (2 . 2) 6)

It is again `setq-local' call with multiple variables. See the attached 
patch that splits it into several parts.From 9bb21fe2354206d3edf0cc7e145f9d4c5a7bd2ec Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Fri, 11 Aug 2023 22:13:17 +0700
Subject: [PATCH] org-macs.el: Fix Emacs-26 compatibility

lisp/org-macs.el (org-string-width): Avoid multiple variables in
`setq-local' since it is not supported by Emacs-26.

The code caused the issue was added in 0c29f53ab8723.
---
 lisp/org-macs.el | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index 9533d7b07..442c607d7 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -1117,9 +1117,9 @@ (defun org-string-width (string  pixels)
  result)))
   (current-char-property-alias-alist char-property-alias-alist))
   (with-current-buffer (get-buffer-create " *Org string width*")
-(setq-local display-line-numbers nil
-line-prefix nil
-wrap-prefix nil)
+(setq-local display-line-numbers nil)
+(setq-local line-prefix nil)
+(setq-local wrap-prefix nil)
 (setq-local buffer-invisibility-spec
 (if (listp current-invisibility-spec)
 (mapcar (lambda (el)
-- 
2.25.1

[BUG][SECURITY] ob-sqlite header args allows execution of arbitrary shell commands

[Max Nikulin]

Consider the following Org file

 8< 
#+begin_src elisp :results none
  (require 'ob-sqlite)
#+end_src

#+begin_src sqlite :db /tmp/ob.sqlite$(date >/tmp/ob-sqlite-vuln.log)
  select 1
#+end_src
 >8 

Executing of the sqlite code block causes creation of the 
/tmp/ob-sqlite-vuln.log file.


The cause is usage of `org-fill-template' without `shell-quote-argument'.

From my point of view it is unsafe to open Org files from untrusted 
sources in Emacs in general, so it is not a serious vulnerability. Some 
users may consider shell expansion in file name as a convenient feature. 
However earlier we had a quite similar issue:


lux. [PATCH] Fix ob-latex.el command injection vulnerability. Sat, 18 
Feb 2023 18:08:44 +0800. 
https://list.orgmode.org/tencent_7b48d6a8d4fcdc2dc8df842b069b715ec...@qq.com


that is known as CVE-2023-28617 with high enough score 
"org-babel-execute:latex in ob-latex.el in Org Mode through 9.6.1 for 
GNU Emacs allows attackers to execute arbitrary commands via a file name 
or directory name that contains shell metacharacters."


and caused updates of Emacs in various Linux distributions
https://security-tracker.debian.org/tracker/CVE-2023-28617

As to `org-fill-template', it may be affected by an issue similar to
Maxim Nikulin. greedy substitution in org-open-file. Wed, 20 Jan 2021 
23:08:35 +0700.

https://list.orgmode.org/ru9ki4$t5e$1...@ciao.gmane.io

since expansion of a %key may contain %another that might be 
interpolated on next iteration. The function should perform substitution 
during single scan of the passed template.

Re: Concerning previews of LaTeX snippets

[Ihor Radchenko]

Divya  writes:

> Whenever I try to do `C-x C-c C-l`, I get the following error:
>
> `org-compile-file: File "/tmp/orgtexEMteNn.svg" wasn't produced Please
> adjust 'dvisvgm' part of 'org-preview-latex-process-alist'`
>
> And following this, I have tried to tweak the value of the variable, but
> nothing seems to be working.

What is the contents of *Org Preview LaTeX Output* buffer?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [SUMMARY] [[bbb:OrgMeetup]] on Wed, Aug 9, 19:00 UTC+3 (was: Interest in an Org video meetup?)

[Ihor Radchenko]

Carlo Tambuatco  writes:

> Was unable to attend due to a power outage. Is this going to be a
> monthly/semi monthly meetup? Is the next one scheduled already?

Not scheduled yet. I am tentatively thinking about the second Wednesday
of September (Wed, Sep 13).

Another idea is to have the meetup scheduled ~2 weeks from now, but at
different time. So that we cover Asia/Pacific time zone without forcing
people to attend at midnight and arrange the time around 6-8pm UTC+8.
But I will need some volunteer to be the host.

I recall that Ravi expressed interest in hosting a meetup (correct me if
I am wrong). Though his time zone might not be the best to synchronize
with Asia/Pacific.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [patch] ox-latex.el: fix blank lines behavior in verse block

[Ihor Radchenko]

Juan Manuel Macías  writes:

> ... In any case, the fact that the verse block can also be used to
> literally export line breaks and horizontal/vertical spaces is
> interesting. Something occurred to me that I don't know if it's a bit
> foolhardy: how about a LaTeX attribute ':literal t'? If used, it would
> not export to a verse environment (specialized in poetry) but to normal
> text, without environment, but with line breaks and horizontal and
> vertical spacing preserved... wdyt?

If one uses verse blocks to export to multiple backends, your suggestion
sounds reasonable. That way, export results will look closer across
different export backends.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Bastien Guerry  writes:

>> Finally, we have org-mouse.el discussed here, which modifies key
>> bindings and org-inlinetask.el, which modifies how Org treats headlines
>> in Org files, modifying syntax.
>
> org-mouse.el should not modify default Org _editing_ key bindings.
> Is it really the case?  If so, can we fix this?

Yes, org-mouse modifies the behavior of certain key bindings. Not
directly, but by advising `org-open-at-point'.
Also, org-mouse adds new key bindings, potentially overriding custom
user bindings for mouse keys.

> Does org-inlinetask.el modifies the way non-inline headlines are
> edited?
> ... If so, can we fix this?  IIRC org-inlinetask.el only adds
> editing function for inline tasks, it is an extension, not a
> modification of the default Org editing behavior, but the limit
> can be thin here.

It changes the very notion of that is a headline - the syntax definition
is altered. Very deeply nested headlines may become inlinetasks upon
loading org-inlinetask, touching all aspects of Org, not just editing.

And it is not clear how to fix this. We did not make inlinetasks into
standard Org syntax in the past and now it is in the weird state when we
have (featurep 'org-inlinetask) sprinkled across the code just to
accommodate for this conditional syntax.

Inlinetasks are too similar in syntax with headlines, so it is
impossible to make the change backwards-compatible.

>> With the current state of affairs, it is often enough to
>> (require 'org-library) to get things work. If we get rid of all the
>> possible side effects, users will have to adapt their configurations
>> and we will thus violate "I won't force you to update your
>> configuration."
>
> Defining new functions is a desirable "side-effect" of all Elisp
> library, I don't think we should worry abou this.

Defining new functions by itself is not a big deal. But there are parts
of Org that alter their behavior depending on whether a feature is
loaded (like org-inlinetask) or depending whether certain function
symbol is defined (babel). Similarly, loading new link types re-defines
Org syntax in all the documents, affecting editing of everything that
looks like the loaded link type (org-ctags).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Re: what is the purpose of "This link has already been stored"?

[Ihor Radchenko]

Bastien Guerry  writes:

> (1) by always store the latest link on top and remove old dups.
>
> (2) always store latest link at the top and remove old dups and allow
> to keep dups with 3 universal prefix args.
> ...
> I'm in favor of option (2) as it deals with the above use-case, and
> storing a link for each lines in the active region should be the
> default behavior anyway, with no need for a prefix arg.
>
> WDYT?

I am not sure if C-u C-u C-u override is the best design.
If the user wants to store duplicates, she will be forced to use C-u C-u
C-u every single time. And a single slip forgetting to use the prefix
arg will clear the already stored duplicates.

Also, it is not clear how to use a single C-u or double C-u C-u yet
keeping duplicates.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Feature request: adjust ~org-agenda-format-item~ to let the user choose the first level included in breadcrumbs

[Ihor Radchenko]

"M. Pger"  writes:

> I understand better, thanks. Would be a good opportunity for me to (try to) 
> contribute; this weekend I will check carefully the link you've sent. I'll 
> keep you posted, your assistance would be more than welcome :)

It has been a month since the last message in this thread.
If you encountered any difficulties and need help understanding the
code, please let us know.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Seemingly inconsistent whitespace ownership

[Ihor Radchenko]

"Tom Alexander"  writes:

> The org-mode documentation states: "With the exception of list items, blank 
> lines belong to the preceding element with the narrowest possible scope. For 
> example, if at the end of a section we have a paragraph and a blank line, 
> that blank line is considered part of the paragraph."
>
> https://orgmode.org/worg/org-syntax.html#org9bc833d
>
> So I created a test org-mode document with exactly that scenario described:
> ...
> and then I ran a M-x eval-expression (message "%s" (pp-to-string 
> (org-element-parse-buffer))) to see the parse tree. I'll paste the output at 
> the end because its a wall of text, but analyzing it:
> ...
> Its only child is a paragraph which has a :begin at 1 and :end at 10, which 
> only includes the line break at the end of "foo bar." but this is exactly the 
> scenario described in the documentation (a paragraph at the end of a section) 
> so I would expect the paragraph to end at 14, not 10.

You are right and you revealed an existing inconsistency between our
incremental and recursive parsers (org-element-parse-buffer is the
recursive parser).

Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=bfe1179dc

Also, in addition to list items, footnote-definitions do not extend
their contents to the trailing blank lines.
I now clarified it in org-syntax document.
https://git.sr.ht/~bzg/worg/commit/3e91f5be

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Passing table to Ruby session

[Ihor Radchenko]

Mike Gauland  writes:

> I've reported it to the inf-ruby project: 
> https://github.com/nonsequitur/inf-ruby/issues/172
>
> I wasn't aware that Emacs would insert EOF in a stream, but that doesn't 
> seem to be the problem (if it is even occurring here).

AFAIK, it has nothing to do with Emacs itself. Rather Linux PTY quirks.
See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=6149

I posted the same link in the github issue.

On Org side, the best we might do is splitting the long command into
multiline (if ruby REPL supports line continuation like \
this or similar). Of course, it will be a workaround.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Or probably just fix the org-ctags hook functions?

[Ihor Radchenko]

Nick Dokos  writes:

>> ...
>> Probably the problem is not the side-effects done by loading
>> =org-ctags=, but rather that these hook function from =org-ctags= try
>> to do their job when the environment is not really ready for them,
>> i.e. when there is no known tag file around.
>> ...
>
> I disagree: the changes are done behind my back in an (almost)
> invisible manner and leave me surprised and mystified. Even if there
> was a TAGS file around, having links behave differently from one
> moment to the next, when the only thing I did in-between was ask for
> help on a completely unrelated Org mode function, is a nasty surprise.

Sure, but we should not reject Jens' proposal just because of this
argument. We can use the suggestions to improve org-ctags itself, after
it is explicitly loaded.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Nick Dokos  writes:

> I would also recommend that the library *not* call its enable function
> in general and leave it to the user to do so explicitly, but that may
> be more controversial for "backward compatibility" reasons (with which
> I disagree in these particular cases: I view them as bugs that need to
> be fixed).

I think that we all agree on this point.
The main question is where to draw a line between intrusive and
non-intrusive side effects.

For example, before loading ob-emacs-lisp

#+begin_src elisp
 (+ 1 1)
#+end_src

will not be syntax-highlighted, while after loading it will.
Is it intrusive? Somewhat. But maybe not bad enough to justify enable
function.

Similarly, loading ob-lilypond will alter how file containing lilypond
fragments is tangled.

Or loading ox-foo.el may alter export menu.

We have plenty of examples with varying degrees of side effects in Org.
And it is not fully clear to me which side effects are worth eliminating
and which are not.

Yet another option could be forcing certain side effects even without
loading. For example,
  (add-to-list 'org-babel-tangle-lang-exts '("LilyPond" . "ly"))
that sets up tangling of lilypond fragments can be changed to

;;;#autoload
(add-to-list 'org-babel-tangle-lang-exts '("LilyPond" . "ly"))

That way, we will consistently get the same tangle configuration even
before ob-lilypond is loaded.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Ihor Radchenko]

Jonathan Gregory  writes:

>> Jonathan, do you think that your original patch is still what 
>> you want to get merged?
>
> Yes, the one I sent on 20 Jul 2023. I haven't had any issues with 
> it so far.

Ok. Would you mind adding a commit message, as described in
https://orgmode.org/worg/org-contribute.html#first-patch?

And do I understand correctly that no changes in
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html
are needed?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at