Re: [BUG] FAQ asnwer for "How can I use arbitrary colors for words/sentences in HTML export?" is outdated

[Max Nikulin]

On 20/01/2024 23:04, Ihor Radchenko wrote:

On 18/02/2023 17:18, Ihor Radchenko wrote:

Inhttps://orgmode.org/worg/org-faq.html#org60202b9, the answer uses
obsolete function `org-add-link-type'. We should change it to
`org-link-set-parameters'.



Fixed.
https://git.sr.ht/~bzg/worg/commit/3194e6d5


Bastien, could you, please, have a look at the CI configuration. I do 
not see recent builds in

https://builds.sr.ht/~bzg/worg

Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export

[Max Nikulin]

On 21/01/2024 01:47, Ihor Radchenko wrote:

Juan Manuel Macías writes:


lorem\\ @@latex:[ipsum]@@ ==> the problem is in the user's territory


I agree with Juan Manuel.


I see your point.
Although I am still a bit hesitant to remove
`org-latex-line-break-safe'.
What would be the benefit of removing it? For now, I mostly just see
that it will make the life harder for users in Scenario B.


An option might be disabling it by default without removing the code 
completely. Depending on user feedback it may be removed later.


Users, who need to submit LaTeX code, consider [0pt] as undesired noise. 
I see their point of view.

Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export

[Max Nikulin]

On 20/01/2024 19:41, Ihor Radchenko wrote:

Max Nikulin writes:


To have an additional excuse, it is better to add a note that it is
inspired by pandoc strategy.


I can add it to the code comment, but for different reason. We do not
give "excuses" to make breaking changes - 
https://bzg.fr/en/the-software-maintainers-pledge/
But we do keep the flexibility to make changes where Org mode behavior
is undefined. Like in this case.


De-facto \\[0pt] was a breaking change despite formal contracts. I do 
not consider it as a wrong decision though. It is the case when where 
was no good choice, instead just ones that may cause some troubles 
(including leaving everything as is).


I recall some threads (besides ones started by Juan Manuel) where users 
considered [0pt] as an undesired consequence of some other changes. That 
is why I wrote "excuse".

Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export

[Max Nikulin]

On 20/01/2024 19:35, Ihor Radchenko wrote:

Max Nikulin writes:


Can anyone think of a possible scenario where removing the '\\[0pt]' in
the last line would cause a problem?


I would suggest to strip leading and trailing newlines before processing
of the block content.


May you elaborate?


I expect that

#+BEGIN_VERSE


From fairest creatures we desire increase,
That thereby beauty’s rose might never die,



#+END_VERSE

is exported to

\begin{verse}
From fairest creatures we desire increase,\\
That thereby beauty’s rose might never die,
\end{verse}

and internally at some point it is represented as
"From fairest creatures we desire increase,\nThat thereby beauty’s rose 
might never die,"

without leading and trailing newlines.


In such scenario, we may technically violate what users ask us to do:

#+begin_verse
I really want newline here\\
#+end_verse


I really want newline here@@latex:\\%@@


This implies that Org mode does not follow its own markup. I disagree
with such suggestion.


I do not see any use case for "\\" at the last line. Perhaps it might 
even cause an org-lint warning. From my point of view, it is preferable 
to require more verbose markup in special cases to make intentions explicit.

Basic citations: problems with quotes in LaTeX export

[William Denton]

While trying out more about basic citations, with quotes to mark strings so I 
can see where whitespace matters, I found that when exporting to LaTeX some 
regular quote marks (") turn into fancy ones (“”) but others don't.

Let's say we have Basic.bib (now in testing/examples/, adjust path as needed) 
and this Org file:

# --
#+bibliography: Basic.bib
#+cite_export: basic

[cite: "prefix one" @friends "suffix one"]

[cite: "global"; "prefix one" @friends "suffix one"; "prefix two" @friends 
'suffix two'; "global"].
# --

Export that to LaTeX and you'll see this (also attached):

https://www.miskatonic.org/tmp/latex-quotes.png

The suffix quote marks don't turn fancy.  Same if you change the citation 
processor to csl.

It's rare to have quotes in citations, but for complex ones with some 
commentary I could certainly imagine them, for example where you want to refer 
to a certain word or mention how an author translates it.  In any case there's 
something unexpected going on here.

Bill

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada

Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export

[Juan Manuel Macías]

Ihor Radchenko writes:

> I see your point.
> Although I am still a bit hesitant to remove
> `org-latex-line-break-safe'.
> What would be the benefit of removing it? For now, I mostly just see
> that it will make the life harder for users in Scenario B.

It's a complicated situation, because we now have two solutions to the
same problem... It certainly sounds a bit abrupt to remove
org-latex-line-break-safe (at least for now). I see no problem in both
solutions coexisting. After all, the user can always give an ""
value to org-latex-line-break-safe. The other possibility is that
org-latex-line-break-safe is selectively deleted, as you mentioned in a
previous email. In tables and verse blocks, unless I'm missing
something, I think adding [0pt] would be unnecessary, with the new
solution.

> For verse blocks, AFAIU, even \\ is problematic. (Correct me if I am wrong)

>From the tests I have done, the problem of the vertical space being
altered after the verse environment only appears when the last line ends
in \\[0pt]. If it ends in \\ the problem does not appear. It is not
recommended that a verse environment ends in \\, but it does not seem to
influence the output. In fact, that was how it was in Org in the days
pre org-latex-line-break-safe and there were never any problems.

Best regards,

Juan Manuel 

Re: [BUG] FAQ asnwer for "How can I use arbitrary colors for words/sentences in HTML export?" is outdated

[Suhail Singh Canary]

Ihor Radchenko  writes:

> Max Nikulin  writes:
>
>> https://list.orgmode.org/87bl21vazj@posteo.net
>>
>> Likely should be modified a bit to support derived backends.
>
> I think we do not do this in any of the examples for :export link
> property in WORG. I am actually not sure how to update things to work
> for derived backends as well.
>
>> The following package might be mentioned:
>>
>> Colours section in org-special-block-extras
>> https://alhassy.com/org-special-block-extras/#Colours
>
> Agree.
> https://git.sr.ht/~bzg/worg/commit/5edf3ab0

For what it's worth, org-special-block-extras doesn't work well with
derived backends yet, either [1].

[1]: 

-- 
Suhail

Re: Backwards compatibility (was: Re: [PATCH] ob-shell: consistent prefix)

[Ihor Radchenko]

Matt  writes:

> How far does backwards compatibility extend with regard to Org itself?
> For the next version, for all time, or something else?

Usually, until next major release (we should have major releases more
frequently in future).

However, we often keep compat code in place even much later if it does
not stay on the way of maintenance or implementing new features.

> The rule I infer from your comment is, "renamed symbols must be
> aliased." This implies that any arguments associated with the symbol
> are the same after the name change. How do we handle changes in
> function APIs? I'm thinking of something like
> =org-babel-execute:shell= and =org-babel-sh-evaluate= where it would
> make sense to refactor the =stdin= and =cmdline= parameters.

1. When we need to add new arguments, we usually add them as optional
   arguments at the end.

2. When we need to remove arguments, we just keep the relevant arglist
   names as _ (indicating that the argument is unused).

3. When API is changing more significantly, we obsolete the old function
   code and keep it in org-compat. Then, we implement a completely new
   function with a new name, and use it throughout Org mode.

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

Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export

[Ihor Radchenko]

Juan Manuel Macías  writes:

> Scenario B:
>
> lorem\\ @@latex:[ipsum]@@ ==> the problem is in the user's territory

I see your point.
Although I am still a bit hesitant to remove
`org-latex-line-break-safe'.
What would be the benefit of removing it? For now, I mostly just see
that it will make the life harder for users in Scenario B.

For verse blocks, AFAIU, even \\ is problematic. (Correct me if I am wrong)

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

Re: [PATCH] Make command org-babel-detangle work interactively

[Ihor Radchenko]

gerard.vermeu...@posteo.net writes:

>> 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.

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

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

Re: [PATCH] ob-shell: consistent prefix

[Matt]

I'm going to defer these changes for now.  It seems like it would be easier to 
handle renaming one function/variable at a time.  Renaming requires creating an 
alias mapping between the old name and the new one.  Any subsequent refactoring 
would require updating the mapping.  It seems better to do any non-naming 
refactoring and then handle aliasing and obsoleting in order to minimize the 
number of changes that need to happen.  Also, renaming now invalidates any 
references, like in my notes or documentation.

I have questions regarding development that I'll ask in a different subject 
thread.

--
Matt Trzcinski
Emacs Org contributor (ob-shell)
Learn more about Org mode at https://orgmode.org
Support Org development at https://liberapay.com/org-mode

Backwards compatibility (was: Re: [PATCH] ob-shell: consistent prefix)

[Matt]

  On Tue, 16 Jan 2024 14:10:00 +0100  Ihor Radchenko  wrote --- 

 > I do not mind changing the names, except that we must not break
 > backwards compatibility.  In particular, the non-private function
 > and variable names that were present in the latest Org stable
 > release must be either supplied with an alias or declared
 > obsolete. Otherwise, the third-party code using the old names will
 > be broken.

How far does backwards compatibility extend with regard to Org itself?  For the 
next version, for all time, or something else?  

The rule I infer from your comment is, "renamed symbols must be aliased."  This 
implies that any arguments associated with the symbol are the same after the 
name change.  How do we handle changes in function APIs?  I'm thinking of 
something like =org-babel-execute:shell= and =org-babel-sh-evaluate= where it 
would make sense to refactor the =stdin= and =cmdline= parameters.

--
Matt Trzcinski
Emacs Org contributor (ob-shell)
Learn more about Org mode at https://orgmode.org
Support Org development at https://liberapay.com/org-mode

Re: [BUG] FAQ asnwer for "How can I use arbitrary colors for words/sentences in HTML export?" is outdated

[Ihor Radchenko]

Max Nikulin  writes:

> On 18/02/2023 17:18, Ihor Radchenko wrote:
>> In https://orgmode.org/worg/org-faq.html#org60202b9, the answer uses
>> obsolete function `org-add-link-type'. We should change it to
>> `org-link-set-parameters'.
>
> Confirmed.

Fixed.
https://git.sr.ht/~bzg/worg/commit/3194e6d5

> A newer recipe:
>
> Juan Manuel Macías to emacs-orgmode… Re: how to export red colored TeX 
> to latex. Tue, 30 Nov 2021 16:56:00 +. 
> https://list.orgmode.org/87bl21vazj@posteo.net
>
> Likely should be modified a bit to support derived backends.

I think we do not do this in any of the examples for :export link
property in WORG. I am actually not sure how to update things to work
for derived backends as well.

> The following package might be mentioned:
>
> Colours section in org-special-block-extras
> https://alhassy.com/org-special-block-extras/#Colours

Agree.
https://git.sr.ht/~bzg/worg/commit/5edf3ab0

> Other files:
> - org-tutorials/org-R/org-variables-counts.org
> - org-tutorials/org-R/variable-popcon.org
> - org-configs/org-customization-survey.org
> - org-configs/org-customization-survey-2013.org

These are not relevant - they contain tables for old Org mode
customization polls.

> Need review:
> - org-hacks.org
>mid: links for org-gnus (not ol-gnus) and org-occur example

Done.
https://git.sr.ht/~bzg/worg/commit/83e85f8e

> - exporters/anno-bib-template-worg.org
>citations using ebib

Thomas kindly updated the whole thing.
https://git.sr.ht/~bzg/worg/commit/c864fe68

> Outdated:
> - org-tutorials/org-latex-export.org
>Org < 8.0

This is also authored by Thomas. I will ask him in another thread.

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

Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export

[Juan Manuel Macías]

Ihor Radchenko writes:

> Juan Manuel Macías  writes:
>
>>> Paragraph\\
>>> @@latex:[foo]@@
>>
>> But since in both cases it is literal LaTeX code, the correct thing
>> would be for the user to be in charge of adding the curly braces to the
>> square brackets. I mean in such scenario it is LaTeX code, not Org.
>
> Not really. Because we do not give guarantees about the details of LaTeX
> export, we should try hard to not break things that users may put into
> literal export snippets.
>
>> Anyway, in both examples it does not make sense for LaTeX to end a
>> paragraph with the \\ macro, which is why we commented in previous
>> messages in the thread. The \\ macro is only used in horizontal mode;
>> this macro does not add a new paragraph but rather a forced line break
>> within the paragraph.
>
> In the example with @@latex:[foo]@@, \\ is not at the end of a paragraph
> - it is inside paragraph.

What I mean is that literal LaTeX code is LaTeX code, despite the
redundancy. IMHO, Org's only duty in that case is to export such literal
code as valid LaTeX code, but Org "does not know" what that literal code
consists of. The user who enters the literal LaTeX code is the one who
has the duty to add the necessary elements to that code so that it is
compiled correctly by LaTeX. Let's look at this as a territorial
question:

Scenario A:

@@LaTeX:\libebreak@@ [ipsum] ==> the problem is in Org territory

Scenario B:

lorem\\ @@latex:[ipsum]@@ ==> the problem is in the user's territory

Best regards,

Juan Manuel 

[PATCH] Change the default value of org-attach-store-link-p to 'attached

[Ihor Radchenko]

Ihor Radchenko  writes:

>> Feel free to propose a patch for this and the suggested switch, we can
>> apply it after Org 9.4.
>
> I will add it to my todo list. This should be lower priority than org-fold.el

See the attached patch.

>From 175937da259fe0b29057d69055bf3469aa1a8679 Mon Sep 17 00:00:00 2001
Message-ID: <175937da259fe0b29057d69055bf3469aa1a8679.1705764051.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Sat, 20 Jan 2024 16:20:20 +0100
Subject: [PATCH] org-attach-store-link-p: Change default value to 'attached

* lisp/org-attach.el (org-attach-store-link-p): Change the default
value.
* etc/ORG-NEWS (The default value of ~org-attach-store-link-p~ is now
~attached~): Announce the change.
---
 etc/ORG-NEWS   | 5 +
 lisp/org-attach.el | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 847ddf614..ea456c67b 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -371,6 +371,11 @@ The change is breaking when ~org-use-property-inheritance~ is set to ~t~.
 
 The =TEST= parameter is better served by Emacs debugging tools.
 ** New and changed options
+*** The default value of ~org-attach-store-link-p~ is now ~attached~
+
+Now, after attaching a file, =[[attach:...]]= link to the attached file
+is stored.  It can later be inserted using =M-x org-insert-link=.
+
 *** New option ~org-fast-tag-selection-maximum-tags~
 
 You can now limit the total number of tags displayed in the fast tag
diff --git a/lisp/org-attach.el b/lisp/org-attach.el
index 58bfcf9ba..81ce9a73c 100644
--- a/lisp/org-attach.el
+++ b/lisp/org-attach.el
@@ -142,7 +142,7 @@ (defcustom org-attach-use-inheritance 'selective
 	  (const :tag "Inherit parent node attachments" t)
 	  (const :tag "Respect org-use-property-inheritance" selective)))
 
-(defcustom org-attach-store-link-p nil
+(defcustom org-attach-store-link-p 'attached
   "Non-nil means store a link to a file when attaching it.
 When t, store the link to original file location.
 When `file', store link to the attached file location.
-- 
2.43.0


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

Re: [BUG] beamer export

[Ihor Radchenko]

Ihor Radchenko  writes:

> Leo Butler  writes:
>
>> The following Org document shows a bug in the beamer exporter.
>
> Confirmed on main.

I investigated further.

> There are two bugs reported here:
> 1. ox-latex export bug for src blocks containing direct LaTeX when
>org-latex-src-block-backend is set to its default 'verbatim value

This appears to be Beamer-specific problem with verbatim environments:
https://tex.stackexchange.com/questions/140719/verbatim-in-beamer-showing-error-file-ended-while-scanning-use-of-xverbatim

The solution might be to use [fragile] frame parameter, but that might
have its own drawbacks:
https://tex.stackexchange.com/questions/136240/drawbacks-of-using-fragile-frames-in-beamer

> 2. ox-beamer export bug as described in the attached org file

This is not a bug. When you specify ignoreheading environment, you imply
that the contents of the heading is to be included as is.
If you want the contents to become a column, you should specify column
environment.

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

Re: [BUG] PRIORITIES does not accept multi-byte unicode characters [9.6.9 (N/A @ /gnu/store/3rxpvdkn907pb1ccm2yl3ffyaz02k7d1-emacs-org-9.6.9/share/emacs/site-lisp/org-9.6.9/)]

[Ihor Radchenko]

Ihor Radchenko  writes:

>> Expected: The lowest priority is selected: [#]
>>
>> Actual: Only the first byte of the lowest priority is selected: [#]
>
> Try M-x describe-char on any of these emojis.
> Org mode relies on `string-to-char' to extract the priority char and
> (insert (string-to-char "")) ;=> 
>
> So, it is a problem with Emacs. You may report it with M-x report-emacs-bug

I am looking into this now, with a different set of system fonts, and it
is now clear what is going on.

 is actually not a single Unicode character, but 2 characters:  and
. The reason they are rendered as emoji is likely font composition
rules.

Org mode priorities _must_ be a single char.

That said, it is indeed confusing when what _appears_ to be a single
char is not under the hood.

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

Re: [PATCH] Make command org-babel-detangle work interactively

[gerard . vermeulen]

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: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export

[Ihor Radchenko]

Juan Manuel Macías  writes:

>> Paragraph\\
>> @@latex:[foo]@@
>
> But since in both cases it is literal LaTeX code, the correct thing
> would be for the user to be in charge of adding the curly braces to the
> square brackets. I mean in such scenario it is LaTeX code, not Org.

Not really. Because we do not give guarantees about the details of LaTeX
export, we should try hard to not break things that users may put into
literal export snippets.

> Anyway, in both examples it does not make sense for LaTeX to end a
> paragraph with the \\ macro, which is why we commented in previous
> messages in the thread. The \\ macro is only used in horizontal mode;
> this macro does not add a new paragraph but rather a forced line break
> within the paragraph.

In the example with @@latex:[foo]@@, \\ is not at the end of a paragraph
- it is inside paragraph.

Another alternative could be modifying how inline latex snippet is
exported, but that's worse IMHO - we should try hard not to touch what
users tell Org to do explicitly.

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

Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export

[Juan Manuel Macías]

Ihor Radchenko writes:

> Juan Manuel Macías  writes:
>
>>> \begin{itemize}
>>> \item {[}bax]
>>> \item {[}aur]
>>> \end{itemize}
>>
>> Great! Simple and effective. And more surgical than pandoc's global
>> solution. But now a question arises... Your code clearly solves the
>> problem that led to the declaration of org-latex-line-break-safe,
>> without foreseeing any unwanted effects, since it is the solution that
>> is usually recommended from LaTeX. So, if this code is included in Org,
>> what is the future of org-latex-line-break-safe?
>
> It is still useful in situations like
>
> Paragraph\\
>
> #+begin_export latex
> [foo]
> #+end_export
>
> or
>
> Paragraph\\
> @@latex:[foo]@@

But since in both cases it is literal LaTeX code, the correct thing
would be for the user to be in charge of adding the curly braces to the
square brackets. I mean in such scenario it is LaTeX code, not Org.

Anyway, in both examples it does not make sense for LaTeX to end a
paragraph with the \\ macro, which is why we commented in previous
messages in the thread. The \\ macro is only used in horizontal mode;
this macro does not add a new paragraph but rather a forced line break
within the paragraph.

Best regards,

Juan Manuel 

Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export

[Ihor Radchenko]

Max Nikulin  writes:

> It means that [0pt] is not necessary any more. However users will have 
> adjust their filters once more. I have no idea if many of them will 
> complain concerning {[} where it is not really required. (/[omitted]/).

We do not promise the exact way the exported LaTeX file looks like. User
filters are too flexible - we cannot reasonably guarantee that they will
keep working if they rely on the way Org mode transcodes to LaTeX in
specific Org version.

> To have an additional excuse, it is better to add a note that it is 
> inspired by pandoc strategy.

I can add it to the code comment, but for different reason. We do not
give "excuses" to make breaking changes - 
https://bzg.fr/en/the-software-maintainers-pledge/
But we do keep the flexibility to make changes where Org mode behavior
is undefined. Like in this case.

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

Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export

[Ihor Radchenko]

Max Nikulin  writes:

>>> Can anyone think of a possible scenario where removing the '\\[0pt]' in
>>> the last line would cause a problem?
>
> I would suggest to strip leading and trailing newlines before processing 
> of the block content.

May you elaborate?

>> In such scenario, we may technically violate what users ask us to do:
>> 
>> #+begin_verse
>> I really want newline here\\
>> #+end_verse
>
> I really want newline here@@latex:\\%@@

This implies that Org mode does not follow its own markup. I disagree
with such suggestion.

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

Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export

[Ihor Radchenko]

Juan Manuel Macías  writes:

>> \begin{itemize}
>> \item {[}bax]
>> \item {[}aur]
>> \end{itemize}
>
> Great! Simple and effective. And more surgical than pandoc's global
> solution. But now a question arises... Your code clearly solves the
> problem that led to the declaration of org-latex-line-break-safe,
> without foreseeing any unwanted effects, since it is the solution that
> is usually recommended from LaTeX. So, if this code is included in Org,
> what is the future of org-latex-line-break-safe?

It is still useful in situations like

Paragraph\\
#+begin_export latex
[foo]
#+end_export

or

Paragraph\\
@@latex:[foo]@@

My patch does not do anything about verbatim environments.

We may remove the use of `org-latex-line-break-safe' from some places,
but not all.

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

Re: [PATCH] Make command org-babel-detangle work interactively

[Ihor Radchenko]

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?
>From 65c8ac3bb1a148106b5673d247ecaaddad291704 Mon Sep 17 00:00:00 2001
Message-ID: <65c8ac3bb1a148106b5673d247ecaaddad291704.1705753074.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Sat, 20 Jan 2024 13:17:43 +0100
Subject: [PATCH] lisp/ob-tangle.el (org-babel-detangle): Improve docstring

---
 lisp/ob-tangle.el | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 933a3eba1..f9953ebed 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -618,9 +618,12 @@ (defun org-babel-tangle-comment-links ( info)
 
 ;; de-tangling functions
 (defun org-babel-detangle ( source-code-file)
-  "Propagate changes in source file back original to Org file.
+  "Propagate changes from current file back to the original Org file.
 This requires that code blocks were tangled with link comments
-which enable the original code blocks to be found."
+which enable the original code blocks to be found.
+
+SOURCE-CODE-FILE is the file path to be used instead of current
+buffer."
   (interactive)
   (save-excursion
 (when source-code-file (find-file source-code-file))
-- 
2.43.0


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

Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export

[Juan Manuel Macías]

Max Nikulin writes:

> On 18/01/2024 20:05, Ihor Radchenko wrote:
>> With the patch, I am getting the following:[...]
>> \begin{center}
>> \begin{tabular}{lr}
>> {[}foo] & 2\\[0pt]
>> {[}bar] & 3\\[0pt]
>> \end{tabular}
>> \end{center}
>
> It means that [0pt] is not necessary any more. However users will have
> adjust their filters once more. I have no idea if many of them will
> complain concerning {[} where it is not really required.
> (/[omitted]/).
>
> To have an additional excuse, it is better to add a note that it is
> inspired by pandoc strategy.

I agree with the note. Perhaps both strategies could coexist: by
default, Ihor's code; and org-latex-line-break-safe with value "".
And, after some time, the latter could become obsolete, unless a new
''raison d'etre'' is found for it...

In any case, I would no longer see it necessary to modify
org-latex-verse-block anymore.

Best regards,

Juan Manuel 

Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export

[Max Nikulin]

On 13/01/2024 22:08, Ihor Radchenko wrote:

Juan Manuel Macías writes:


Can anyone think of a possible scenario where removing the '\\[0pt]' in
the last line would cause a problem?


I would suggest to strip leading and trailing newlines before processing 
of the block content.



In such scenario, we may technically violate what users ask us to do:

#+begin_verse
I really want newline here\\
#+end_verse


I really want newline here@@latex:\\%@@

P.S. Juan Manuel, I have sent another message to this thread without 
your address in Cc.

Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export

[Max Nikulin]

On 18/01/2024 20:05, Ihor Radchenko wrote:

With the patch, I am getting the following:[...]
\begin{center}
\begin{tabular}{lr}
{[}foo] & 2\\[0pt]
{[}bar] & 3\\[0pt]
\end{tabular}
\end{center}


It means that [0pt] is not necessary any more. However users will have 
adjust their filters once more. I have no idea if many of them will 
complain concerning {[} where it is not really required. (/[omitted]/).


To have an additional excuse, it is better to add a note that it is 
inspired by pandoc strategy.