[Tex/LaTex] Why not use \cr instead of \\ in tables

siunitxtables

In plain TeX \cr is used to mark the end of a row in a table.
In LaTeX \\ is usually used instead.

\\ takes an optional argument, which \cr does not support. But I never use that anyway, I prefer booktabs' \addlinespace.

As I have found out recently \\ does not always work, see this bug which was closed with this commit which adds a subsection to the documentation explaining that \cr should be used instead. If the last column of a table is a S column (defined by the siunitx package) and text is appended to this column (with the array package's <{...} syntax) the spacing is wrong when using \\ but correct when using \cr.

So I am wondering: Why not always use \cr instead of \\ to denote the end of a row in a table?

Best Answer

The argument against using \cr is really the generic argument that applies to any use of undocumented internal interfaces in any software.

\cr is not a documented latex command, the documented commands to end table rows are \\ and \tabularnewline.

In the default implementation, if you are not using the * form or [] argument, \\ basically just does \cr so using \cr directly comes to the same thing. However as it isn't a documented latex command the implementation of tables could change so that they were not equivalent, also conversions of latex to html etc have no reason to expect to see \cr in a document and so may fail.

If some package has a bug that means \cr is needed then that's a bug that should be fixed, or if some package defines an environment where \cr is expected then it is that package documentation not latex documentation (or this answer) that says if you should use it.

Related Solutions

[Tex/LaTex] \arraybackslash doing on the table column

As with almost everything in TeX, control sequences (macros and control words) can be redefined, and because local grouping allows for local redefinition, the definitions of macros within a particular environment can be different from the definitions outside of that environment. This is the case of \\, which has multiple definitions depending on the environment.

In normal text, \\ is defined as:

\let \reserved@e \relax \let \reserved@f \relax \@ifstar 
 {\let \reserved@e \vadjust \let \reserved@f \nobreak \@xnewline }
 \@xnewline

Inside a tabular environment, it is defined as:

 \@tabularcr

which expands to:

 {\ifnum 0=`}\fi \@ifstar \@xtabularcr \@xtabularcr

Inside a raggedright environment, \\ is redefined to be

 \@centercr

which expands to:

 \ifhmode \unskip \else \@nolnerr \fi \par \@ifstar {\nobreak \@xcentercr }\@xcentercr

Since these definitions are different, after using a \raggedright environment in a tabular you need to use \arraybackslash to restore it to its tabular definition.

In addition to the question you linked to, see also:

What is the difference between \newline and \\?

[Tex/LaTex] siunitx error: Invalid numerical input

You correctly surmised that the opening parenthesis is always treated as marking the start of the uncertainty. This is necessary for siunitx to be able to reliably parse numbers. The option table-space-text-pre does not change this; it only adds the width of its value (( in this case) to the column, the actual token (() is not treated any differently because of this.

You can still achieve your goal without redefining the uncertainty input by hiding the parentheses from the parser. This can be done by putting them inside a group (between { and }). It looks like you already tried this in >{{(}}, but the error message tells you that this group is not there any more when the siunitx parser reads the parenthesis. How can this be?

When TeX consumes the argument of a macro, it strips it of one layer of braces (if present). This means that sometimes, depending on the implementation of the macros you are using, some of the braces you type disappear before they reach the part of the machine they were meant for.

There are two ways of dealing with this.

You could add more braces. In your case, one additional layer is enough: >{{{(}}}
You can hide your braces from TeX by putting them inside a macro. Define a macro \newcommand*\foo{{(}} and use it like >{\foo}. Now, when this argument is handed through the different macros implementing the table, \foo is still unexpanded. It only gets expanded once the siunitx parser tries to make sense of its input and then it finds {(}, as desired. In general, this approach is much safer and easier than the first one since you don't have to first find out how many layers of braces you need and your code does not break when this number changes.

As to why this does not occur in older versions of siunitx I can only guess. To me, it looks like either a bug in the old versions or a new feature in the new ones. (Being able to add parts of the number before parsing using > and < is definitely a feature, I would say.)

Best Answer

Related Solutions

[Tex/LaTex] \arraybackslash doing on the table column

[Tex/LaTex] siunitx error: Invalid numerical input

Related Question