Safe counterpart of \\ without optional parameters

[maxnikulin]

It is well known issue that in the following snippet square brackets are considered as a part of the \\ command despite they are separated by newline

\begin{tblr}{rl}
a      & b     \\
[1, 2] & [3, 4]
\end{tblr}

It is not a real problem when LaTeX commands are typed by a human. Consider an application with another kind of primary markup that uses LaTeX as an intermediate format to produce PDF files. What do you think concerning adding a command that acts like \\ but does not have optional * and [<LENGTH>] arguments? The purpose is to allow quite simple code generators that do not need forward lookup or other tricks.

Tabularray is quite special case in this sense. Other packages allows to protect table newline or text line break by \\\empty or \\{} while tblr uses a specific parser. (Side note: \\\relax as in #20 causes misplaced \noalign error when followed by \hline.) Perhaps \\[0pt] is a more generic workaround, however I considered \empty as real no-op variant.

expand=\empty outer spec helps, but if I got it correctly only one command may be expanded, so I would prefer to reserve such feature.

By simple LaTeX code generator I mean a visitor that walks through AST in depth first order and joins string produced by children nodes in post hook. In such approach following text and command is not known. Analyzing first character of first cell may be suitable for tables, but for text paragraphs it is not so easy.

So I propose to add a command similar to \\ but having no pitfall due to square brackets in the following text (I do not mind to have it even outside of tabularray). Have I missed an obvious robust workaround?

[maxnikulin]

At first I did not noticed the difference between original report in #20

\begin{tblr}{c|cccc}
	\times & [1] & [2] & [3] & [4]\\\relax
	\hline\relax

and the closing comment

$\begin{tblr}{c|cccc}
 \times & [1] & [2] & [3] & [4] \\
\hline\relax

There is no \relax before \hline in the latter case. E.g. in \begin{tabular} \relax causes an error as well, but \empty has no such problem. I am looking for a "safe" new row command that works even if followed by `\hline'.

[lvjr]

It is reliable to add \empty after \\ and \hline.

\documentclass{article}
\usepackage{tabularray}
\begin{document}
\begin{tblr}{rl}
a      & b      \\\empty
[1, 2] & [3, 4] \\\hline\empty
[1, 2] & [3, 4] 
\end{tblr}
\end{document}

[maxnikulin]

It is reliable to add \empty after \\ and \hline.

Consider internal representation of table structure as

- table row
  - cell
  - cell
- table row
  - cell
  - cell
- hline

So during export of a row it is not known if it followed by another row (and possibly brackets in first cell) or an hline. So either safe new row command should be added at the end of each row or alternatively \empty or \relax command should be added at the start of each row (unsure if some pitfalls exist on this way as well).

\relax cell & cell \\
\relax cell & cell \\
\hline

If \\\empty (and \\{}, etc.) cause errors with following \hline, the next candidate is \\[0pt] with some overhead. My optimistic expectation is a new command with no optional arguments recognized by tabularray and perhaps even adapted by LaTeX core for line breaks in paragraphs and various environments.

I admit that the problem with an exporter unaware of context may sound artificial. E.g. for HTML there is no element for horizontal line, so CSS properties for table rows must be adjusted. As a result not so dumb technique for exporter should be implemented anyway.

[lvjr]

Add \NewTableCommand\empty{}, then you can write \\\empty\hline\empty in tabularray tables.

[maxnikulin]

Add \NewTableCommand\empty{}, then you can write \\\empty\hline\empty in tabularray tables.

Thank you for the suggestion, it works.

Unsure if we will follow this way though. It requires to determine if the tabularray package is used in the document or tables are exported as tabular environment and to add \NewTableCommand\empty{} only in the former case. The variant with \\[0pt] has some advantages from this point of view.

Side note: I mentioned HTML exporter and horizontal lines, but that task is easier. Analysis of result of cell content formatting is not necessary. It is enough to group rows without lines in between into <tbody>.

[lvjr]

\NewTableCommand\empty{} should be put outside tblr environments. But it doesn't affect tabular environments.

[maxnikulin]

\NewTableCommand\empty{} should be put outside tblr environments. But it doesn't affect tabular environments.

\NewTableCommand can not be unconditionally added to preamble. The tabularray package may be unavailable in user's environment. E.g. it is shipped in the optional texlive-latex-extra Debian package, Ubuntu-20.04 LTS focal distribution has too old LaTeX for tabularray. So at first it may be necessary to iterate over all tables in the document to check if some of them havetblr option. It is not really difficult, but it makes the workaround non-local to particular tables.

My intention was to ask if \empty should work out of the box and to discuss if a safe alternative of \\ should be supported.I see you do not like these ideas, and I have no reasons to insist.

The workaround you suggested is bearable, however it has some non-zero cost. Other approaches are not significantly better. Even in optimistic scenario some complications would remain and the reason is some level of backward compatibility.

[lvjr]

After reading the related discussion on orgmode maillist, I have added \NewTableCommand\empty{} to the package (see #328).

[maxnikulin]

I have added \NewTableCommand\empty{} to the package (see #328).

Thank you for this change.

I am not familiar with LaTeX3 code, so the following may be a false alarm. In the description I have noticed \relax defined as {}. Unfortunately for TeX engine \relax is not the same as empty command. In tables \\\relax\hline causes \noalign error.

[u-fischer]

You could define \\ as amsmath does: in an align, a space or a newline interrupts the parsing for the optional argument:

\documentclass{article}
\usepackage{amsmath}
\begin{document}

\begin{align}
a\\ [blub] b
\end{align}

\begin{align}
a\\
[blub] b
\end{align}

[lvjr]

mainly because of backwards compatibility with a history of 40+ years.

Maybe I am wrong about some of the following facts: amstex is nearly as old as latex and the above change to it occured in recent years and it caused no much compatibility complain (also some rollback command exists).

[FrankMittelbach]

• amstex is not relevant as it couldn't be used with LaTeX, but yes amsmath is also nearly 30 years old.
• define recent for me. It was done by Michael Downes (or I should say iniated by him) and Michael died in 2003. from my vague recollection it came around the time amsmath was set to be a LaTeX package (before there was a separate format for LaTeX + ams stuff but it may have been in there already)
• I'm not aware of rollback code (but maybe I have forgotten).

More importantly, that change isn't one that doesn't signal itself with some error that you can correct, instead it simply turns your optional argument into text to typeset .. which is kind of the worst thing that can happen.

[lvjr]

• define recent for me. It was done by Michael Downes (or I should say iniated by him) and Michael died in 2003. from my vague recollection it came around the time amsmath was set to be a LaTeX package (before there was a separate format for LaTeX + ams stuff but it may have been in there already)
• I'm not aware of rollback code (but maybe I have forgotten).

Sorry, I have bad memory. The breaking change to amsmath in recent years should be the \! change.

More importantly, that change isn't one that doesn't signal itself with some error that you can correct, instead it simply turns your optional argument into text to typeset .. which is kind of the worst thing that can happen.

Are there any better solutions for tabular/array? Maybe some day I will find some time to look into the source code of array package.

[FrankMittelbach]

the source code of array goes back to the '80 (I guess it was the first package of mine together with doc) so it is certainly not a model of good software development.

[maxnikulin]

But that latter workaround is wrong assuming we are inside math mode: it changes the spacing because it turns open atoms int ord atoms and the two have different spacing depending on what comes next.

You are right concerning spacing, but it seems pandoc does not use {[} in math mode. It is not really pure example, but I have not invented anything better. I created a formula in LibreOffice.

pandoc -t latex test.odt 
\[\begin{matrix}
{{\lbrack{a,b}\rbrack} \in P} \\
{{\lbrack{c,d}\rbrack} \in Q} \\
{n \neq m} \\
\end{matrix}\]

[ is not used and every cell is wrapped into {...} thus no need to terminate \\.

Since this discussion is mostly for tabularray, I have an idea to create a feature request for the LaTeX3 project. Tools like Org mode or pandoc would benefit from officially supported way to prevent \\[ issues. It might be a new command similar to \\ (so compatibility should not hurt too much) or a declaration that various packages should be ready to ignore\empty.

[lvjr]

This bug has been fixed (see issue #526). From tabularray v2025A the results of the following two tables are different:

\begin{tblr}{rl}
a      & b     \\
[1em] & [3, 4]
\end{tblr}

\begin{tblr}{rl}
a      & b     \\%
[1em] & [3, 4]
\end{tblr}