# Redefine \or form within a nested if statement?

It's apparently a bad idea to redefine \or so that it renders as \lor in mathmode. However, while trying anyhow, I faced two issues that I would like to understand better. I followed the approach 1, 2

\let\@oldor\or
\def\or{\ifmmode\lor\else\expandafter\@oldor\fi}


However, after moving that into another if statement (checking the package option overwrite \or) it stopped working. Instead, I got the ! Extra \or. error.

By chance, I discovered that I get the same error when I'm trying to use \verb|\or| in a footnote (overleaf).

Any chance how I can rewrite the \def without the expandafter, so that it works anywhere, no matter how many if statements are nested?

• If you redefine \or, then any conditional based on \ifcase will cease to work, no matter how you do the definition. Note that \verb is illegal in a footnote, with any contents. – egreg Mar 5 '18 at 0:18
• Welcome! Can you please edit your question to provide a complete minimal example which produces the error you report, together with the complete text of the error message? – cfr Mar 5 '18 at 0:18
• Although, as egreg says, this is essentially a doomed project. – cfr Mar 5 '18 at 0:24
• You cn't use \verb in a footnote regardless of whether you have \or in it. \footnote{\verb|or|} fails too, albeit with a different error. The problem here is something like putting fragile code in a moving argument, although I'm not sufficiently knowledgeable to be able to explain exactly what that means :(. – cfr Mar 5 '18 at 0:47

TL;DR

You can't redefine \or.

Consider this plain TeX example:

\let\originalor\or
\def\or{\ifmmode\lor\else\expandafter\originalor\fi}

$a\or b$ (works)

\ifcase1
0\or
1\or
2\else
BUMMER\fi

\let\or\originalor

\ifcase1
0\or
1\or
2\else
BUMMER\fi

\bye


Guess what you get from the two \ifcase statements. Yes, the first one yields “BUMMER”, while the other one, with \or restored to its primitive meaning, yields the expected 1.

Why is that? In order to skip the cases, TeX needs to see the primitive \or (a control sequence let to the primitive \or would do as well). So if you redefine \or, no macro based on \ifcase will work as expected.

Well, they will work, but only when the tested integer is 0, because in this case TeX will expand the redefined \or, finding \originalor and so skipping up to the matching \fi. In the “BUMMER” case, the whole 0\or 1\or 2 counts as the text for the 0 case (because there is no primitive \or in it).

This is essentially the same as redefining \fi or any other conditional.

• Thanks. That explains my observations and it gives new ideas how I can approach the larger problem: Rendering \or as \lor in mathmode. I have two ideas: 1) try to redefine the primitive or when math mode is started and restore it when math mode is left. 2) read the tex book and understand how Tex works – physikerwelt Mar 5 '18 at 5:42
• @physikerwelt 2 is a possibility but don't try 1: things will break. – David Carlisle Mar 5 '18 at 7:43
• @physikerwelt: before trying 1) you should check e.g. in amsmath.sty how often \ifcase with \or is used in math mode. – Ulrike Fischer Mar 5 '18 at 8:47
• @UlrikeFischer thanks. However, given the large list of required package and 7 million formulae to process I will probably do some preprocessing and postpone the deeper understanding of the math processing of TeX to a later point in time. – physikerwelt Mar 5 '18 at 9:26
• @physikerwelt I don't understand your remark. I only wanted to make clear that you can't redefine \or in math mode as it is heavily used there too. – Ulrike Fischer Mar 5 '18 at 9:30

Just want to point out something that may be obvious (and in your case you've surely considered already), but is often ignored: if your desire is simply that you'd like to type \or in your personal .tex file or in formulas, and have it treated as if you'd typed \lor, then you can do this by processing the input (specifically, the parts entered manually by you or the user) externally, rather than via a TeX macro.

(For simplicity of illustration let's assume you want \or treated as \lor everywhere in your input file, not just in math mode. The example below shows that redefining \or only in math mode can also cause issues, so there's not much to gain by treating math mode specially anyway.)

Concretely, consider the following input file:

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

\makeatletter
\let\@oldor\or
\def\or{\ifmmode\lor\else\expandafter\@oldor\fi}
\makeatother

$$(x < 0) \or (x = 0) \or (x > 0)$$

\begin{align}
\allowdisplaybreaks[1]
a &= b \\
c &= d
\end{align}
\end{document}


It fails with a hard-to-debug error on reaching the \end{align} line, because \allowdisplaybreaks uses \or internally. See the following from amsmath.sty:

\interdisplaylinepenalty\@M
\newcommand{\allowdisplaybreaks}[1][4]{%
\interdisplaylinepenalty\getdsp@pen{#1}\relax
}
\def\getdsp@pen#1{%
\ifcase #1\@M \or 9999 \or 6999 \or 2999 \or \z@\fi
}


Instead of redefinining \or in TeX, we can get rid of the redefinition (the part inside \makeatletter … \makeatother above), and simply replace every occurrence of \or with \lor with an external script. (E.g. something like sed 's/\\or$$[^a-zA-Z]$$/\\lor\1/g' on your file will do.)

With LuaTeX (if our setup allows using that, which in your Mediawiki-texvc case probably not) we can do this inside the file itself if we want:

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

\begin{luacode*}

luatexbase.add_to_callback('process_input_buffer',
function(line)
return line:gsub([[\or([^a-zA-Z])]], [[\lor%1]])
end,
[[Replaces each \or in the input with \lor]])

\end{luacode*}

$$(x < 0) \or (x = 0) \or (x > 0)$$

\begin{align}
\allowdisplaybreaks[1]
a &= b \\
c &= d
\end{align}
\end{document}


Unlike the earlier version, this doesn't cause any issues from uses of \or in macros that were defined earlier.

• thank you for your suggestion. That was exactly the direction in which I wanted to go next. My idea was to hoop into the 'parsing' part of tex and change the tokens consumed in math mode. – physikerwelt Mar 7 '18 at 7:59