The following gets me this error
! Incomplete \iffalse; all text was ignored after line
26.
So, how to make \if work inside the table stored in the macro \MyTable?
\newif\ifShowRow
\ShowRowfalse
\begin{filecontents*}[overwrite]{mytable.tex}
1 & 2 \\
3 & 4 \\
\ifShowRow
5 & 6 \\
\fi
7 & 8 \\
9 & 10 \\
\end{filecontents*}
\documentclass{article}
\usepackage{catchfile, tabularray}
\UseTblrLibrary{siunitx}
\begin{document}
\CatchFileDef{\MyTable}{mytable.tex}{}
\begin{tblr}[ long, expand = \MyTable ]{ colspec = {X S} }
One & {{{Two}}} \\
\MyTable
\end{tblr}
\end{document}
Update
Adopting this answer, I couldn't manage to make the code below work
\newif\ifShowRow
\ShowRowfalse
\begin{filecontents*}[overwrite]{mytable.tex}
1 & 2 \\
% https://tex.stackexchange.com/a/58627/2288
\ifthenelse{\boolean{ShowRow}}{ 3 & 4 \\ 5 & 6 \\ }{ 7 & 8 \\ 9 & 10 \\}
9 & 10 \\
\end{filecontents*}
\documentclass{article}
\usepackage{catchfile, tabularray, xifthen}
\UseTblrLibrary{siunitx}
\begin{document}
\CatchFileDef{\MyTable}{mytable.tex}{}
\begin{tblr}[ long, expand = \MyTable ]{ colspec = {X S} }
One & {{{Two}}} \\
\MyTable
\end{tblr}
\end{document}
Best Answer
Environments coming from the package tabularray parse their "bodies" for the scaffold/the framework of the table. Seems the parsing-routines "expect" the tokens forming the scaffold/framework of the table to be present in the environment-body as is. Seems the parsing-routines "expect" not to need to obtain these tokens by having carried out in whatsoever way things that come from the "bodies" of these environments.
Expansion is one way/one concept of carrying out things in TeX.
In order to have a bit of expansion-support while that parsing is done, with recent releases of the tabularray-package the
expand=...-key is provided, but that in turn implies that tokens provided as value of that key must be fully expandable.But
\ifthenelseis not fully expandable.\ifthenelseis a macro which, beneath other things, yields tokens that are intended to trigger the performing of temporary assignments/to trigger the (re)defining of temporary macros/scratch-macros.TeX does not carry out assignments in the stage of expansion but it does so in a later stage of its "digestive processes".
Using Donald E. Knuth's analogy of TeX being a beast with eyes and a digestive tract, expansion takes place in the gullet and assignments are carried out in the stomach, when expansion is already done.
With environments coming from the package tabularray a lot of parsing-work for detecting the scaffold/framework of the table is done by means of "internal" routines provided by the package. Tokens coming from the body of the environment and forming arguments of these internal routines do not get expanded for further examination. They are not carried out in whatsoever way. Unless they occur as value of the
expand=...-key. Seems in this case triggering one step of expansion is the only way of "carrying out" which is possible. Performing assignments is not possible.I used the phrase "one step of expansion" because usually in TeX's gullet expansion is a "process of regurgitation". I.e., if expanding an expandable token yields another expandable token now being the first token of the token-stream, that other expandable token will be expanded, too. Seems with the
expand=...-key that regurgitation does not take place. You just get that other expandable token and that's it.But you can easily establish "regurgitation":
As a trick you can trigger expansion of
\romannumeralusingexpand = \romannumeraland (ab?)use\romannumeral-expansion for triggering a lot of expansion-work.The gist of
\romannumeral-expansion is:\romannumeralgathers tokens until (either) having gathered a set of tokens that form a valid TeX-⟨number⟩-quantity (or seeing the need of raising an error-message). Expandable tokens are expanded while gathering.In case the TeX-⟨number⟩-quantity does denote an integer which is positive, you get explicit character-tokens of category 12(other) that form the representation in lowercase roman numerals of the value currently represented by that TeX-⟨number⟩-quantity.
In case the TeX-⟨number⟩-quantity does denote an integer which is not positive, the tokens forming that TeX-⟨number⟩-quantity are silently discarded without whatsoever (disturbing error-)message and without TeX returning any tokens.
The latter case is more interesting for our purposes:
You can (ab?)use
\romannumeralfor triggering TeX to do a lot of (macro-)expansion-work (="token-replacing"-work) and "exchanging-tokens-in-the-token-stream"-work/"flipping-tokens-around-in-the-token-stream"-work as long as it is ensured that after all this expansion- and exchanging-/flipping-work the very next token in the token-stream is a TeX-⟨number⟩-quantity denoting an integer whose value is not positive.In the example below for providing the TeX-⟨number⟩-quantity denoting an integer whose value is not positive I use the token
\stopexpansion, defined as\chardef\stopexpansion=`\^^00.\stopexpansionis a\chardef-token and in the context of gathering a TeX-⟨number⟩-quantity is assumed to denote the value "0" which is not positive. TeX's rules for gathering a TeX-⟨number⟩-quantity say that no optional trailing spaces or whatever will be discarded when the TeX-⟨number⟩-quantity in question is formed by a\chardef-token. Besides this\stopexpansionis also a control-word-token and therefore is not affected by things like\uppercaseor\lowercase.In the example below, for triggering expansion I actually use
\romannumeral. But I use it as a token\startexpansionwhich via\letis made equal to\romannumeral.Besides this with tables in general you need to ensure that things like
&and\\are nested in curly braces until the very last step of expansion is done, whereafter only those tokens remain that should actually form the framework/scaffold of the table.Otherwise TeX's own mechanisms for parsing/detecting the framework/scaffold of a table might intercept expansion and take things for the content of a table-cell that actually should be removed by expansion.
You can do this, e.g., by passing things as brace-nested macro-arguments, e.g., for
\@firstoftwoor\@secondoftwo.(
\@firstoftwois a macro of the LaTeX 2ε-kernel which picks the first of two undelimited/brace-nested arguments.\@secondoftwois a macro of the LaTeX 2ε-kernel which picks the second of two undelimited/brace-nested arguments.)If you like you can place
\stopexpansioninto the definition-text of\ExpandableConditionCheckTrueFalse.Then the syntax of
\ExpandableConditionCheckTrueFalsein any case, also outside tabularray-environments, is\startexpansion\ExpandableConditionCheckTrueFalse{<name of \if-switch without leading "if">}{<true code>}{<false code>}.I.e.,
\ExpandableConditionCheckTrueFalsemust always be preceded by\startexpansion(or by\romannumeral).(By the way: I decided for ⟨name of \if-switch without leading "if"⟩ instead of providing the
\if..-token directly because this way you won't have unbalanced\if..-tokens on toplevel of your code. Otherwise you would have to write things likeHere
\ifShowRowis not balanced by\fiwhich can cause trouble when embedded in surrounding\if..-\else-\fi-expressions because\if..-\else-\fi-nesting is independent from any kind of group-nesting, i.e., is independent from brace-group-nesting also.)I cannot recommend "hiding"
\startexpansionwithin another macro.Currently
expand =...will be applied to one token only.I.e., with
\begin{tblr}[expand = \foo, expand = \bar ]the directiveexpand = \barwill override the directiveexpand = \fooand only expansion of\barwill be triggered while parsing the body of the environment.When "hiding"
\startexpansionwithin another macro, then you would need to applyexpand=<that other macro-token wherein \startexpansion is hidden>which wouldexpand=\startexpansion. I.e., you could not use\startexpansionany more for triggering expansion of other things. E.g., you would not have means for triggering the expansion of the macro defined via\CatchFileDef.But I can give you a macro for better expansion-control and avoiding large chains of
\expandafter:Here is how it could be integrated into a MWE:
If you wish, you can hardcode
\Expandstepsinto\ExpandableConditionCheckTrueFalse—if you do that, then, like with hardcoding\stopexpansioninto\ExpandableConditionCheckTrueFalse, each instance of\ExpandableConditionCheckTrueFalseneeds to be preceded by\startexpansion. So when it comes to nesting, a smaller amount of expansion-steps needs to be triggered as each\startexpansionitself will trigger some more, but the token\startexpansionneeds to be provided more often:If you don't hardcode
\Expandstepsor\stopexpansioninto\ExpandableConditionCheckTrueFalseyou need to specify more expansion-steps but you don't need\startexpansionso often:If you don't want to keep track of the amount of expansion-steps just don't hardcode things and instead place
\stopexpansionas first token of each final branch: