Export of this table fails LuaLaTeX compilation

Export of this table fails LuaLaTeX compilation

[gerard.vermeulen]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

Hello,

I am regularly updating 9.6-pre from https://elpa.gnu.org/devel/ and 
yesterday
my LaTeX export stopped working.  The org-mode snippet below (attached, 
together
with the LaTeX export file) shows the problem.  The LaTeX file compiles 
after I remove
all occurrences of \relax.

Best -- Gerard

#+title: Export of this table fails LuaLaTeX compilation
#+macro: nit (eval (format "@@latex:\\colorbox{red}{\\texttt{%s}}@@" 
$1))
#+options: title:nil toc:nil
Macro {{{nit(works outside table)}}} but fails inside tables where
=\\= matters. The LaTeX export fails to compile with LuaLaTeX because
of =\\\relax= instead of =\\=:
|-----------------------------------------|
| @@latex:\colorbox{red}{\texttt{bug}}@@  |
| {{{nit(bug)}}}                          |
|-----------------------------------------|
exports to:
#+begin_src latex :exports none :results silent
   \begin{center}
   \begin{tabular}{l}
   \hline
   \colorbox{red}{\texttt{bug}}\\\relax
   \colorbox{red}{\texttt{bug}}\\\relax
   \hline
   \end{tabular}
   \end{center}
#+end_src

[-- Attachment #2: bug.tex --]
[-- Type: application/x-tex, Size: 1269 bytes --]

[-- Attachment #3: bug.org --]
[-- Type: application/octet-stream, Size: 739 bytes --]

#+title: Export of this table fails LuaLaTeX compilation
#+macro: nit (eval (format "@@latex:\\colorbox{red}{\\texttt{%s}}@@" $1))
#+options: title:nil toc:nil
Macro {{{nit(works outside table)}}} but fails inside tables where
=\\= matters. The LaTeX export fails to compile with LuaLaTeX because
of =\\\relax= instead of =\\=:
|-----------------------------------------|
| @@latex:\colorbox{red}{\texttt{bug}}@@  |
| {{{nit(bug)}}}                          |
|-----------------------------------------|
exports to:
#+begin_src latex :exports none :results silent
  \begin{center}
  \begin{tabular}{l}
  \hline
  \colorbox{red}{\texttt{bug}}\\\relax
  \colorbox{red}{\texttt{bug}}\\\relax
  \hline
  \end{tabular}
  \end{center}
#+end_src

Re: Export of this table fails LuaLaTeX compilation

[Ihor Radchenko]

gerard.vermeulen@posteo.net writes:

> I am regularly updating 9.6-pre from https://elpa.gnu.org/devel/ and 
> yesterday
> my LaTeX export stopped working.  The org-mode snippet below (attached, 
> together
> with the LaTeX export file) shows the problem.  The LaTeX file compiles 
> after I remove
> all occurrences of \relax.
> ...
> #+begin_src latex :exports none :results silent
>    \begin{center}
>    \begin{tabular}{l}
>    \hline
>    \colorbox{red}{\texttt{bug}}\\\relax
>    \colorbox{red}{\texttt{bug}}\\\relax
>    \hline
>    \end{tabular}
>    \end{center}
> #+end_src

Confirmed.
But what is the problem here? Isn't \relax supposed to work in LuaTeX?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Export of this table fails LuaLaTeX compilation

[Max Nikulin]

On 12/10/2022 11:15, Ihor Radchenko wrote:
> 
> Confirmed.
> But what is the problem here? Isn't \relax supposed to work in LuaTeX?

LuaLaTeX is irrelevant. It seems \hline is allowed only immediately 
after \\. Minimal LaTeX example:

\begin{tabular}{l}
b\\\relax
\hline
\end{tabular}

Re: Export of this table fails LuaLaTeX compilation

[gerard.vermeulen]

On 12.10.2022 06:15, Ihor Radchenko wrote:
> gerard.vermeulen@posteo.net writes:
> 
>> I am regularly updating 9.6-pre from https://elpa.gnu.org/devel/ and
>> yesterday
>> my LaTeX export stopped working.  The org-mode snippet below 
>> (attached,
>> together
>> with the LaTeX export file) shows the problem.  The LaTeX file 
>> compiles
>> after I remove
>> all occurrences of \relax.
>> ...
>> #+begin_src latex :exports none :results silent
>>    \begin{center}
>>    \begin{tabular}{l}
>>    \hline
>>    \colorbox{red}{\texttt{bug}}\\\relax
>>    \colorbox{red}{\texttt{bug}}\\\relax
>>    \hline
>>    \end{tabular}
>>    \end{center}
>> #+end_src
> 
> Confirmed.
> But what is the problem here? Isn't \relax supposed to work in LuaTeX?

It does not work on my Mac with texlive-2020, so I export my org file, 
open it and replace
all occurrences of \\\relax with \\ before compiling.  I have to confirm 
this on Gentoo Linux
with texlive-2022 at work.

I think that \\ signals the end of a table row and that \relax ends up 
on the next row with
missing fields.

Re: Export of this table fails LuaLaTeX compilation

[gerard.vermeulen]

On 12.10.2022 06:45, Max Nikulin wrote:
> On 12/10/2022 11:15, Ihor Radchenko wrote:
>> 
>> Confirmed.
>> But what is the problem here? Isn't \relax supposed to work in LuaTeX?
> 
> LuaLaTeX is irrelevant. It seems \hline is allowed only immediately
> after \\. Minimal LaTeX example:
> 
> \begin{tabular}{l}
> b\\\relax
> \hline
> \end{tabular}

Your example fails on my Mac texlive-2020 with:

! Misplaced \noalign.
\hline ->\noalign
                   {\ifnum 0=`}\fi \hrule \@height \arrayrulewidth 
\futurelet...

l.40 \hline

It compiles when I remove \hline

Re: Export of this table fails LuaLaTeX compilation

[Max Nikulin]

On 12/10/2022 12:15, gerard.vermeulen wrote:
> On 12.10.2022 06:45, Max Nikulin wrote:
>>
>> LuaLaTeX is irrelevant. It seems \hline is allowed only immediately
>> after \\. Minimal LaTeX example:
>>
>> \begin{tabular}{l}
>> b\\\relax
>> \hline
>> \end{tabular}
> 
> Your example fails on my Mac texlive-2020 with:
> 
> ! Misplaced \noalign.
> \hline ->\noalign
>                    {\ifnum 0=`}\fi \hrule \@height \arrayrulewidth 
> \futurelet...
> 
> l.40 \hline
> 
> It compiles when I remove \hline

Gerard, we forgot to post the reason why \relax has been added after \\. 
The intention was to  prevent errors in the case of

| a   |
| [b] |

or

- item \\
   [2022-10-12]

Stewart Thomas. [BUG] Tables with square brackets do not compile in PDF 
(latex) export. Wed, 10 Nov 2021 11:16:10 -0500. 
https://list.orgmode.org/CAO12V+wB18nAN0FuDPAeN94GHdt_2nbdJtc4u7n4W3HAZbaZsA@mail.gmail.com

I can not figure out an easy way to separate \\ from [b] text but to 
prevent the problem you have discovered. I am unsure if

     \\[0pt]

has no negative consequences and safe enough. I expect that LaTeX 
sources are not easy to read when fragile sequences of tokens are involved.

I just have realized that some users might take advantage of earlier 
behavior as a feature:

- item \\
   [1cm]
- item

I think that [1cm] should be treated as text, however I have no idea how 
to allow users to specify amount of vertical space and to not limit line 
break to LaTeX only. @@latex:\\[1cm]@@ is not suitable when the same 
text should be exported to ascii, html, etc.

Re: Export of this table fails LuaLaTeX compilation

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> Gerard, we forgot to post the reason why \relax has been added after \\. 
> The intention was to  prevent errors in the case of
>
> | a   |
> | [b] |
>
> or
>
> - item \\
>    [2022-10-12]
>
> Stewart Thomas. [BUG] Tables with square brackets do not compile in PDF 
> (latex) export. Wed, 10 Nov 2021 11:16:10 -0500. 
> https://list.orgmode.org/CAO12V+wB18nAN0FuDPAeN94GHdt_2nbdJtc4u7n4W3HAZbaZsA@mail.gmail.com
>
> I can not figure out an easy way to separate \\ from [b] text but to 
> prevent the problem you have discovered. I am unsure if
>
>      \\[0pt]
>
> has no negative consequences and safe enough. I expect that LaTeX 
> sources are not easy to read when fragile sequences of tokens are involved.

What about adding \relax in front of table rows instead of at the end?
The hlines are transcoded separately.

All other instances of \\\relax may remain.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Export of this table fails LuaLaTeX compilation

[Max Nikulin]

On 12/10/2022 14:26, Ihor Radchenko wrote:
> Max Nikulin writes:
>>
>> I can not figure out an easy way to separate \\ from [b] text but to
>> prevent the problem you have discovered. I am unsure if
>>
>>       \\[0pt]
>>
>> has no negative consequences and safe enough. I expect that LaTeX
>> sources are not easy to read when fragile sequences of tokens are involved.
> 
> What about adding \relax in front of table rows instead of at the end?
> The hlines are transcoded separately.
> 
> All other instances of \\\relax may remain.

If you see a way to implement it, you may try. Do not forget a space 
after it. Spaces at the beginning of line are insignificant, so 
insertion of \relax should not cause more ignored spaces than it was 
before. I would consider skipping "\relax " in the beginning of rows 
where first cell starts from an export snippet.

I am considering \noalign{} instead of \relax. I was never aware of its 
effect, but accordingly to The TeXbook it should keep TeX in vertical 
mode without any action due to empty argument. (Actually I surprised 
that \relax causes any change of internal state besides parser.) 
Unfortunately \noalign{} just as \relax will not allow @@latex:[1cm]@@ 
on the next line, perhaps @@latex:\noalign{\vskip 1cm}@@ is a workaround 
to introduce additional vertical space.

     \\[0pt]

causes insertion of some code for negative vertical skip (of zero height 
this case). It should not be really harmful, but I would avoid this hack.

I never used \\* or \\*[10pt] variants of the command. Current stable 
release should has problems when the line next to \\ starts from * that 
is not bold marker, besides square brackets.

Re: Export of this table fails LuaLaTeX compilation

[gerard.vermeulen]

On 12.10.2022 07:55, Max Nikulin wrote:
> On 12/10/2022 12:15, gerard.vermeulen wrote:
>> On 12.10.2022 06:45, Max Nikulin wrote:
>>> 
>>> LuaLaTeX is irrelevant. It seems \hline is allowed only immediately
>>> after \\. Minimal LaTeX example:
>>> 
>>> \begin{tabular}{l}
>>> b\\\relax
>>> \hline
>>> \end{tabular}
>> 
>> Your example fails on my Mac texlive-2020 with:
>> 
>> ! Misplaced \noalign.
>> \hline ->\noalign
>>                    {\ifnum 0=`}\fi \hrule \@height \arrayrulewidth 
>> \futurelet...
>> 
>> l.40 \hline
>> 
>> It compiles when I remove \hline
> 
> Gerard, we forgot to post the reason why \relax has been added after
> \\. The intention was to  prevent errors in the case of
> 
> | a   |
> | [b] |
> 
> or
> 
> - item \\
>   [2022-10-12]
> 
> Stewart Thomas. [BUG] Tables with square brackets do not compile in
> PDF (latex) export. Wed, 10 Nov 2021 11:16:10 -0500.
> https://list.orgmode.org/CAO12V+wB18nAN0FuDPAeN94GHdt_2nbdJtc4u7n4W3HAZbaZsA@mail.gmail.com
> 
> I can not figure out an easy way to separate \\ from [b] text but to
> prevent the problem you have discovered. I am unsure if
> 
>     \\[0pt]
> 
> has no negative consequences and safe enough. I expect that LaTeX
> sources are not easy to read when fragile sequences of tokens are
> involved.
> 
> I just have realized that some users might take advantage of earlier
> behavior as a feature:
> 
> - item \\
>   [1cm]
> - item
> 
> I think that [1cm] should be treated as text, however I have no idea
> how to allow users to specify amount of vertical space and to not
> limit line break to LaTeX only. @@latex:\\[1cm]@@ is not suitable when
> the same text should be exported to ascii, html, etc.

Max, thanks for the background information.

For your info:
1. I also need to remove \relax in the LaTeX export using Gentoo 
texlive-2022 to compile.
2. On my systems ws-butler removes the trailing whitespace.
3. I edited your example with nano to add the trailing space after 
\relax, but it still does not compile.

Re: Export of this table fails LuaLaTeX compilation

[Max Nikulin]

On 12/10/2022 16:17, gerard.vermeulen@posteo.net wrote:
> 
> 
> On 12.10.2022 07:55, Max Nikulin wrote:
>> On 12/10/2022 12:15, gerard.vermeulen wrote:
>>> On 12.10.2022 06:45, Max Nikulin wrote:
>>>>
>>>> LuaLaTeX is irrelevant. It seems \hline is allowed only immediately
>>>> after \\. Minimal LaTeX example:
>>>>
>>>> \begin{tabular}{l}
>>>> b\\\relax
>>>> \hline
>>>> \end{tabular}
>>>
>>> Your example fails on my Mac texlive-2020 with:
>>>
>>> ! Misplaced \noalign.
>>> \hline ->\noalign
>>>                    {\ifnum 0=`}\fi \hrule \@height \arrayrulewidth 
>>> \futurelet...
>>>
>>> l.40 \hline
>>>
>>> It compiles when I remove \hline
>>
>> Gerard, we forgot to post the reason why \relax has been added after
>> \\. The intention was to  prevent errors in the case of
>>
>> | a   |
>> | [b] |
>>
>> or
>>
>> - item \\
>>   [2022-10-12]
>>
>> Stewart Thomas. [BUG] Tables with square brackets do not compile in
>> PDF (latex) export. Wed, 10 Nov 2021 11:16:10 -0500.
>> https://list.orgmode.org/CAO12V+wB18nAN0FuDPAeN94GHdt_2nbdJtc4u7n4W3HAZbaZsA@mail.gmail.com
>>
>> I can not figure out an easy way to separate \\ from [b] text but to
>> prevent the problem you have discovered. I am unsure if
>>
>>     \\[0pt]
>>
>> has no negative consequences and safe enough. I expect that LaTeX
>> sources are not easy to read when fragile sequences of tokens are
>> involved.
>>
>> I just have realized that some users might take advantage of earlier
>> behavior as a feature:
>>
>> - item \\
>>   [1cm]
>> - item
>>
>> I think that [1cm] should be treated as text, however I have no idea
>> how to allow users to specify amount of vertical space and to not
>> limit line break to LaTeX only. @@latex:\\[1cm]@@ is not suitable when
>> the same text should be exported to ascii, html, etc.
> 
> Max, thanks for the background information.
> 
> For your info:
> 1. I also need to remove \relax in the LaTeX export using Gentoo 
> texlive-2022 to compile.

Adding \relax is my fault, I did not expect that it may break \hline. 
Such behavior should be stable over decades. The question is how to 
allow users to have square brackets in the beginning of the line 
following \\ and not break some use case.

> 2. On my systems ws-butler removes the trailing whitespace.
> 3. I edited your example with nano to add the trailing space after 
> \relax, but it still does not compile.

Sorry, I did not get your point with trailing space. LaTeX ignores 
spaces after commands (e.g. "a\relax b" becomes "ab") and in the 
beginning of the line. What I am afraid of is unintentionally introduce 
white space at the beginning of the line, e.g. if
| a |
| b |
|---|
is exported as
{} a \\
{} b \\
\hline
then cell contents will be " a" and " b", not "a" and "b".
\relax a \\
\relax b \\
\hline
has no such problem.

Re: Export of this table fails LuaLaTeX compilation

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> On 12/10/2022 14:26, Ihor Radchenko wrote:
>> Max Nikulin writes:
>>>
>>> I can not figure out an easy way to separate \\ from [b] text but to
>>> prevent the problem you have discovered. I am unsure if
>>>
>>>       \\[0pt]
>>>
>>> has no negative consequences and safe enough. I expect that LaTeX
>>> sources are not easy to read when fragile sequences of tokens are involved.
>> 
>> What about adding \relax in front of table rows instead of at the end?
>> The hlines are transcoded separately.
>> 
>> All other instances of \\\relax may remain.
>
> If you see a way to implement it, you may try. Do not forget a space 
> after it. Spaces at the beginning of line are insignificant, so 
> insertion of \relax should not cause more ignored spaces than it was 
> before. I would consider skipping "\relax " in the beginning of rows 
> where first cell starts from an export snippet.
>
> I am considering \noalign{} instead of \relax. I was never aware of its 
> effect, but accordingly to The TeXbook it should keep TeX in vertical 
> mode without any action due to empty argument. (Actually I surprised 
> that \relax causes any change of internal state besides parser.) 

If \noalign has less side effects compared to \relax, I'd prefer
\noalign. Can you confirm this?

I was also surprised that \relax does anything except escaping.

> Unfortunately \noalign{} just as \relax will not allow @@latex:[1cm]@@ 
> on the next line, perhaps @@latex:\noalign{\vskip 1cm}@@ is a workaround 
> to introduce additional vertical space.
>
>      \\[0pt]

What you are talking about appears to be abusing our exporter. We give
no guarantees about how \\ is going to be exported internally into
LaTeX. We should have no obligation to keep use-cases like this.

> causes insertion of some code for negative vertical skip (of zero height 
> this case). It should not be really harmful, but I would avoid this hack.
>
> I never used \\* or \\*[10pt] variants of the command. Current stable 
> release should has problems when the line next to \\ starts from * that 
> is not bold marker, besides square brackets.

I feel like I am missing what you are talking about here.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Export of this table fails LuaLaTeX compilation

[Max Nikulin]

[-- Attachment #1: Type: text/plain, Size: 3062 bytes --]

On 13/10/2022 09:44, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
>> I am considering \noalign{} instead of \relax. I was never aware of its
>> effect, but accordingly to The TeXbook it should keep TeX in vertical
>> mode without any action due to empty argument. (Actually I surprised
>> that \relax causes any change of internal state besides parser.)
> 
> If \noalign has less side effects compared to \relax, I'd prefer
> \noalign. Can you confirm this?

My understanding of TeX is not solid enough to confirm this. From The 
TeXbook I have an impression that \noalign is added specially for 
table-like blocks to be used immediately after \cr (low level command 
similar to \\). So I would not use it outside of tables however it may 
be safe. I am not aware of problems with \\\noalign{} in tables. The 
exact effect of \relax is not clear to me yet. I do not have an example 
of negative effect of \relax similar to \hline but outside of tables.

I can try to ask for a better suggestion at stackexchange, but I am 
unsure if the question will be noticed by some person from a TeX engine 
or core LaTeX developers or at least with better understanding of TeX 
internals.

>> Unfortunately \noalign{} just as \relax will not allow @@latex:[1cm]@@
>> on the next line, perhaps @@latex:\noalign{\vskip 1cm}@@ is a workaround
>> to introduce additional vertical space.
> 
> What you are talking about appears to be abusing our exporter. We give
> no guarantees about how \\ is going to be exported internally into
> LaTeX. We should have no obligation to keep use-cases like this.

On the other hand LaTeX backend was transparent to such hacks, so the 
change might be breaking to some users. That is why conditionally adding 
\noalign{} or \relax if \\ is not followed by an export snippet may be a 
better solution.

>> I never used \\* or \\*[10pt] variants of the command. Current stable
>> release should has problems when the line next to \\ starts from * that
>> is not bold marker, besides square brackets.
> 
> I feel like I am missing what you are talking about here.

The rabbit hole is deeper than I thought. The \\ command has its star 
counterpart \\* to prevent page break at this point, and both of them 
allow optional [<LENGTH>] argument. In vanilla LaTeX2e space is allowed 
between \\ and *. However \usepackage{amsmath} redefines \\ command. It 
still can recognize following *, but only on the same line. Unsure if it 
is a bug or feature. So before your commit the following is not a 
problem in *default* Org configuration:

Star\\
@@ignore:@@* on the next line.

Star and brackets\\
*[1em] on the next line.

| Star |
| * in the next row. |
|-|
| Star and brackets |
| *[1em] in the next row. |

However it might be if someone changes list of default packages. Adding 
\noalign{} and \relax should fix the issue just for square brackets.

So at least as a temporary fix \noalign{} should be used for tables 
instead of \relax to mitigate negative effect of the recent patch.

P.S. Packages like longtable might bring more surprises.

[-- Attachment #2: doublebackslash.tex --]
[-- Type: text/x-tex, Size: 937 bytes --]

\documentclass{article}
%\usepackage{amsmath}
\begin{document}
\section{Regular usage}

Just\\
line break.

Brackets\\[1em]
on the same line.

Star\\*
on the same line.

Star and brackets\\*[1em]
on the same line.

\begin{tabular}{l}
tabular\\
\hline
Two\\
rows\\
\hline
Brackets \\[1em]
in the same row\\[1pt]
\hline
Star \\*
in the same row\\*
\hline
Start and brackets\\*[1em]
in the same row\\*[1pt]
\hline
\end{tabular}

\section{Problems}
Brackets and starts disappear in the beginning of
lines and table rows.

Brackets\\
[1em] on the next line.

\begin{tabular}{l}
tabular\\
\hline
Brackets \\
[1em] in the next row\\
[1pt]
\hline
\end{tabular}

\section{Problems when usepackage\{amsmath\} absent}

Star\\
* on the next line.

Star and brackets\\
*[1em] on the next line.

\begin{tabular}{l}
tabular\\
\hline
Star\\
* in the next row. \\
\hline
Star and brackets\\
*[1em] in the next row. \\
\hline
\end{tabular}
\end{document}

Re: Export of this table fails LuaLaTeX compilation

[gerard.vermeulen]

On 12.10.2022 18:21, Max Nikulin wrote:
[...]
>>> Stewart Thomas. [BUG] Tables with square brackets do not compile in
>>> PDF (latex) export. Wed, 10 Nov 2021 11:16:10 -0500.
>>> https://list.orgmode.org/CAO12V+wB18nAN0FuDPAeN94GHdt_2nbdJtc4u7n4W3HAZbaZsA@mail.gmail.com
>>> 
>>> I can not figure out an easy way to separate \\ from [b] text but to
>>> prevent the problem you have discovered. I am unsure if
>>> 
>>>     \\[0pt]
>>> 
>>> has no negative consequences and safe enough. I expect that LaTeX
>>> sources are not easy to read when fragile sequences of tokens are
>>> involved.
>>> 
>>> I just have realized that some users might take advantage of earlier
>>> behavior as a feature:
>>> 
>>> - item \\
>>>   [1cm]
>>> - item
>>> 
>>> I think that [1cm] should be treated as text, however I have no idea
>>> how to allow users to specify amount of vertical space and to not
>>> limit line break to LaTeX only. @@latex:\\[1cm]@@ is not suitable 
>>> when
>>> the same text should be exported to ascii, html, etc.
[...]
> Adding \relax is my fault, I did not expect that it may break \hline.
> Such behavior should be stable over decades. The question is how to
> allow users to have square brackets in the beginning of the line
> following \\ and not break some use case.
> 
>> 2. On my systems ws-butler removes the trailing whitespace.
>> 3. I edited your example with nano to add the trailing space after 
>> \relax, but it still does not compile.
> 
> Sorry, I did not get your point with trailing space. LaTeX ignores
> spaces after commands (e.g. "a\relax b" becomes "ab") and in the
> beginning of the line. What I am afraid of is unintentionally
> introduce white space at the beginning of the line, e.g. if
> | a |
> | b |
> |---|
> is exported as
> {} a \\
> {} b \\
> \hline
> then cell contents will be " a" and " b", not "a" and "b".
> \relax a \\
> \relax b \\
> \hline
> has no such problem.

Sorry, I have misread or misunderstood what \relax does with spaces.
Thank you for your patient explanation -- Gerard

Re: Export of this table fails LuaLaTeX compilation

[Leo Butler]

On Thu, Oct 13 2022, Max Nikulin <manikulin@gmail.com> wrote:

> On 13/10/2022 09:44, Ihor Radchenko wrote:
>> Max Nikulin writes:
>> 
>>> I am considering \noalign{} instead of \relax. I was never aware of its
>>> effect, but accordingly to The TeXbook it should keep TeX in vertical
>>> mode without any action due to empty argument. (Actually I surprised
>>> that \relax causes any change of internal state besides parser.)
>> If \noalign has less side effects compared to \relax, I'd prefer
>> \noalign. Can you confirm this?
>
> My understanding of TeX is not solid enough to confirm this. From The
> TeXbook I have an impression that \noalign is added specially for 
> table-like blocks to be used immediately after \cr (low level command
> similar to \\). So I would not use it outside of tables however it may 
> be safe. I am not aware of problems with \\\noalign{} in tables. The
> exact effect of \relax is not clear to me yet. I do not have an
> example of negative effect of \relax similar to \hline but outside of
> tables.
>
> I can try to ask for a better suggestion at stackexchange, but I am
> unsure if the question will be noticed by some person from a TeX
> engine or core LaTeX developers or at least with better understanding
> of TeX internals.
>
>>> Unfortunately \noalign{} just as \relax will not allow @@latex:[1cm]@@
>>> on the next line, perhaps @@latex:\noalign{\vskip 1cm}@@ is a workaround
>>> to introduce additional vertical space.
>> What you are talking about appears to be abusing our exporter. We
>> give
>> no guarantees about how \\ is going to be exported internally into
>> LaTeX. We should have no obligation to keep use-cases like this.
>
> On the other hand LaTeX backend was transparent to such hacks, so the
> change might be breaking to some users. That is why conditionally
> adding \noalign{} or \relax if \\ is not followed by an export snippet
> may be a better solution.
>
>>> I never used \\* or \\*[10pt] variants of the command. Current stable
>>> release should has problems when the line next to \\ starts from * that
>>> is not bold marker, besides square brackets.
>> I feel like I am missing what you are talking about here.
>
> The rabbit hole is deeper than I thought. The \\ command has its star
> counterpart \\* to prevent page break at this point, and both of them 
> allow optional [<LENGTH>] argument. In vanilla LaTeX2e space is
> allowed between \\ and *. However \usepackage{amsmath} redefines \\
> command. It still can recognize following *, but only on the same
> line. Unsure if it is a bug or feature. So before your commit the
> following is not a problem in *default* Org configuration:
>
> Star\\
> @@ignore:@@* on the next line.
>
> Star and brackets\\
> *[1em] on the next line.
>
> | Star |
> | * in the next row. |
> |-|
> | Star and brackets |
> | *[1em] in the next row. |
>
> However it might be if someone changes list of default
> packages. Adding \noalign{} and \relax should fix the issue just for
> square brackets.
>
> So at least as a temporary fix \noalign{} should be used for tables
> instead of \relax to mitigate negative effect of the recent patch.
>
> P.S. Packages like longtable might bring more surprises.

Maybe Org should not use \\ to end lines in a latex-exported table?
The fact that it has many variations argues against its use in Org, IMO.

My suggestion is to use the TeX command \cr.

Or, define a command in the exported latex, something like

\newcommand{\orgcr}{\cr}

and end rows in a table with \orgcr.

Someone who really wants \\ with its variations can redefine \orgcr and
everyone else can just enjoy the simplicity of Org.

Leo

[PATCH] ox-latex: Use \empty instead of \relax after \\

[Max Nikulin]

[-- Attachment #1: Type: text/plain, Size: 786 bytes --]

On 13/10/2022 21:27, Leo Butler wrote:
> 
> Maybe Org should not use \\ to end lines in a latex-exported table?
> The fact that it has many variations argues against its use in Org, IMO.
> 
> My suggestion is to use the TeX command \cr.

Various LaTeX packages may redefine \\, so low level \cr might be not 
enough. Actually I do not like that \\ does not have a robust 
counterpart with no optional arguments.

> Or, define a command in the exported latex, something like
> 
> \newcommand{\orgcr}{\cr}

It is better to make `org-latex-line-break-safe' a user option instead 
of a constant.

For a record. Unlike \\, \newline does not have optional argument, but
{\centering a\\b\par} and {\centering a\newline b\par} are not equivalent.

I hope, \empty will behave better than \relax.

[-- Attachment #2: 0001-ox-latex-Use-empty-instead-of-relax-after.patch --]
[-- Type: text/x-patch, Size: 3627 bytes --]

From d79da60e6dcfb2f3d7c0a1f5abf9ee2bc684a15c Mon Sep 17 00:00:00 2001
In-Reply-To: <87wn93re80.fsf@t14.reltub.ca>
References: <87wn93re80.fsf@t14.reltub.ca>
From: Max Nikulin <manikulin@gmail.com>
Date: Thu, 13 Oct 2022 22:08:29 +0700
Subject: [PATCH] ox-latex: Use \empty instead of \relax after \\

* lisp/ox-latex.el (org-latex-line-break-safe, org-latex-table-row):
* testing/lisp/test-org-table.el (test-org-table/to-latex): Use \empty
instead of \relax to prevent interpreting following "*" and "[" as
optional parts of \\*[LENGTH] command.

Fix regression introduced by 3f60acff77. \\\relax\hline caused
misaligned \noalign error. Org markup:

    | a |
    |---|

\hline is allowed only immediately after \cr while \relax has some side
effects. Hope, \empty just expands to nothing.

Those who used \\ optional argument to adjust amount of space between
lines may add the following tricks:

    First,\\
    @@latex:{\vskip1em}@@second.

    | First                               |
    | @@latex:\noalign{\vskip1em}@@second |

Reported in
gerard.vermeulen, Wed, 12 Oct 2022 03:15:49 +0000.
https://list.orgmode.org/784cf8be450b7d676ddd60214cc847db@posteo.net
---
 lisp/ox-latex.el               | 12 ++++++------
 testing/lisp/test-org-table.el |  6 +++---
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index eed5dc898..aff90f611 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -278,17 +278,17 @@ list can be:
 
 - `:lang-name' the actual name of the language.")
 
-(defconst org-latex-line-break-safe "\\\\\\relax"
+(defconst org-latex-line-break-safe "\\\\\\empty"
   "Linebreak protecting the following [...].
 
-Without \"\\relax\" it would be interpreted as an optional argument to
+Without \"\\empty\" it would be interpreted as an optional argument to
 the \\\\.
 
 This constant, for example, makes the below code not err:
 
 \\begin{tabular}{c|c}
-    [t] & s\\\\\\relax
-    [I] & A\\\\\\relax
+    [t] & s\\\\\\empty
+    [I] & A\\\\\\empty
     [m] & kg
 \\end{tabular}")
 
@@ -4005,9 +4005,9 @@ a communication channel."
 			      (org-export-get-parent-table table-row) info))))
 	   (format "%s
 \\endfirsthead
-\\multicolumn{%d}{l}{%s} \\\\\\relax
+\\multicolumn{%d}{l}{%s} \\\\\\empty
 %s
-%s \\\\\\relax\n
+%s \\\\\\empty\n
 %s
 \\endhead
 %s\\multicolumn{%d}{r}{%s} \\\\
diff --git a/testing/lisp/test-org-table.el b/testing/lisp/test-org-table.el
index 3e7f18a10..722c37ea4 100644
--- a/testing/lisp/test-org-table.el
+++ b/testing/lisp/test-org-table.el
@@ -1635,11 +1635,11 @@ See also `test-org-table/copy-field'."
 (ert-deftest test-org-table/to-latex ()
   "Test `orgtbl-to-latex' specifications."
   (should
-   (equal "\\begin{tabular}{l}\na\\\\\\relax\n\\end{tabular}"
+   (equal "\\begin{tabular}{l}\na\\\\\\empty\n\\end{tabular}"
 	  (orgtbl-to-latex (org-table-to-lisp "| a |") nil)))
   ;; Test :environment parameter.
   (should
-   (equal "\\begin{tabularx}{l}\na\\\\\\relax\n\\end{tabularx}"
+   (equal "\\begin{tabularx}{l}\na\\\\\\empty\n\\end{tabularx}"
 	  (orgtbl-to-latex (org-table-to-lisp "| a |")
 			   '(:environment "tabularx"))))
   ;; Test :booktabs parameter.
@@ -1648,7 +1648,7 @@ See also `test-org-table/copy-field'."
     "\\toprule" (orgtbl-to-latex (org-table-to-lisp "| a |") '(:booktabs t))))
   ;; Handle LaTeX snippets.
   (should
-   (equal "\\begin{tabular}{l}\n\\(x\\)\\\\\\relax\n\\end{tabular}"
+   (equal "\\begin{tabular}{l}\n\\(x\\)\\\\\\empty\n\\end{tabular}"
 	  (orgtbl-to-latex (org-table-to-lisp "| $x$ |") nil)))
   ;; Test pseudo objects and :raw parameter.
   (should
-- 
2.25.1

Re: [PATCH] ox-latex: Use \empty instead of \relax after \\

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> It is better to make `org-latex-line-break-safe' a user option instead 
> of a constant.

I am not sure. It is so subtle that I doubt that users can safely
customize it without high chances of breaking export. If really needed,
it is anyway possible to setq constant in Elisp anyway. With
unpredictable consequences, of course.

> I hope, \empty will behave better than \relax.
> From d79da60e6dcfb2f3d7c0a1f5abf9ee2bc684a15c Mon Sep 17 00:00:00 2001
> In-Reply-To: <87wn93re80.fsf@t14.reltub.ca>
> References: <87wn93re80.fsf@t14.reltub.ca>
> From: Max Nikulin <manikulin@gmail.com>
> Date: Thu, 13 Oct 2022 22:08:29 +0700
> Subject: [PATCH] ox-latex: Use \empty instead of \relax after \\

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

I consider this bug resolved.
Fixed.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>