# Math inside \text

Math inside \text looses the information that it is inside a subscript $X_{a+b,\text{\ensuremath{a+b}}}$.

\documentclass{article}
\usepackage{amsmath}
\begin{document}
$X_{a+b,\text{\ensuremath{a+b}}}$
\end{document}


I'd like to find different ways to "fix" that.

Background: This is for my package mhchem. There is no striking use case I can think of, right now. It's more of a "make it consistent" feature.

If you use, for instance \ce{H2O} in text mode, then my package will typeset this correctly using the current text font, so it will also look nice in headlines and TOCs. It basically uses math mode with some \texts. I give the user the freedom to insert math anywhere they wish, and they could even write something like \ce{NO_{2n + $\sum_i x_i + y_i$} or something else. I had to choose such a weird example, because all the sensible expressions (n, 2n, 2n+1) already get a special treatment. However, I still want to allow any math expression there, no matter how weird and nested.

• In this case you don't want \text but just \mathrm. – campa Jul 25 '17 at 12:42
• Your MWE shows the problem well enough, but could you also include a real-world example of where it arises? For example @campa says to not use \text, but maybe your application requires the use of \text. – Steven B. Segletes Jul 25 '17 at 12:47

The \text macro indeed loses the information that it is being used in subscripts or superscripts.

Here is a possible patch, but probably using a different macro would be better. If you plan to use it in your package, the users should be warned about the difference with the standard \text command as defined by amsmath.

\documentclass{article}
\usepackage{amsmath}
\usepackage{xpatch}

\makeatletter
\newcommand{\remove@spaces}{%
\thickmuskip=0mu
\medmuskip=0mu
}
\xpatchcmd{\text@}
{\textdef@\textstyle\sf@size}
{\textdef@{\textstyle\remove@spaces}\sf@size}
{}{}
\xpatchcmd{\text@}
{\textdef@\textstyle\ssf@size}
{\textdef@{\textstyle\remove@spaces}\ssf@size}
{}{}
\makeatletter

\begin{document}

$X_{a+b<c\sin x,\text{text$a+b<c\sin x$}}$

$\displaystyle x+\text{text$a+b<c\sin x$}$

$x+\text{text$a+b<c\sin x$}$

\end{document}


If you want to define a new command, say \ttext, you can do (with \usepackage{amsmath}, of course)

\makeatletter
\newcommand{\remove@spaces}{%
\thickmuskip=0mu
\medmuskip=0mu
}
\DeclareRobustCommand{\ttext}{%
\ifmmode\expandafter\ttext@\else\expandafter\mbox\fi}
\def\ttext@#1{{\mathchoice
{\textdef@\displaystyle\f@size{#1}}%
{\textdef@\textstyle\f@size{\firstchoice@false #1}}%
{\textdef@{\textstyle\remove@spaces}\sf@size{\firstchoice@false #1}}%
{\textdef@{\textstyle\remove@spaces}\ssf@size{\firstchoice@false #1}}%
\check@mathfonts
}%
}
\makeatother


This calls \mathchoice just once.

• Wow! Why are you patching twice? Is this recursive? This is probably so you can replace just these spaces that are med/thick in text style (like around operators) – and in scriptstyle we need to keep the thin space after \sin, but not around the operators. But frankly, I don't understand your code in depth. Could you give me a hint? Would it be easier to understand with a new command instead of double-patching the existing one? – mhchem Jul 25 '17 at 13:18
• @mhchem The hint is looking at the code in amstext.sty. – egreg Jul 25 '17 at 13:29
• Indeed, indeed! – mhchem Jul 25 '17 at 14:19
• @mhchem I added a more efficient definition for \ttext – egreg Jul 25 '17 at 17:24

Same approach as egreg's answer. But in a form that much better fits into my brain. (I created it to see if my understanding of egreg's solution was correct.)

\documentclass{article}
\usepackage{amsmath}

\newcommand\ttext[1]{\mathchoice%
{\text{#1}}%
{\text{#1}}%
{\thickmuskip=0mu\medmuskip=0mu\text{#1}}%
{\thickmuskip=0mu\medmuskip=0mu\text{#1}}}

\begin{document}

$X_{a+b<c\sin x,\ttext{text$a+b<c\sin x$}},a+b<c$

$\displaystyle x+\ttext{text$a+b<c\sin x$}$

$x+\ttext{text$a+b<c\sin x$}$

\end{document}


• Well, this typesets 16 subformulas/boxes at each call. – egreg Jul 25 '17 at 14:56
• Not a lazy evaluation – or better: lazy execution – then. :-) As I learned today, from you. – mhchem Jul 25 '17 at 17:20
• Indeed, quite greedy! – Steven B. Segletes Jul 25 '17 at 18:24