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