# Reduce code duplication newcommand

I was wondering how to reduce the duplication of code when using \newcommand. The following code is highlights for explaining things, full TeX code can be found here and the compiled PDF here:

\newcommand\transone{\ensuremath{\ket{2,2} \rightarrow \ket{1,1}}\xspace}
\newcommand\transtwo{\ensuremath{\ket{1,1} \rightarrow \ket{2,0}}\xspace}
\newcommand\transfull{\ensuremath{\ket{2,2} \rightarrow \ket{1,1} \rightarrow \ket{2,0}}\xspace}
\newcommand\ground[1]{\ensuremath{\ket{\text{#1}}}\xspace}
\newcommand\exited{\ensuremath{\ket{\text{e}}}\xspace}


Then you can declare something like declaring a \newmathcommand instead:



And then declare commands by

\newmathcommand\transone{\ket{2,2} \rightarrow \ket{1,1}}


to reduce redundancy. But this prevents me from passing arguments like with \ground. Is there a way to assemble a command that can pass arguments such that you can declare that a command takes input, like this:

\newmathcommand\ground[1]{\ket{\text{#1}}}


Best, Theis

• In my opinion you should simply say \newcommand{\exited}{\ket{\text{e}}. You gain nothing in being able to use \exited in text mode; in that case type $\exited$ and you have no problem with spaces. – egreg Dec 6 '13 at 10:10

## 2 Answers

In fact, that's not so difficult. You just need to "pick up" the optional argument with a trick. See this example:

\documentclass{article}

\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{xspace}

\makeatletter
\def\newmathcommand#1#{\@newmathcommand{#1}}
\def\@newmathcommand#1#2{\newcommand#1{\ensuremath{ #2 } \xspace}}
\makeatother

\newmathcommand\ground[1]{\ket\limits^{\text{#1}}}
\DeclareMathOperator\ket{ket}

\begin{document}

\ground{foo}blah

\end{document}


The #{ notation I used is a special form of "delimited argument". The construct \def\newmathcommand#1#{ means that the argument #1 will contain everything until the opening brace.

It would probably also work to use the usual LaTeX mechanism for optional arguments on \newmathcommand, but as the optional argument goes first by default, it would be more cumbersome.

You need neither \ensuremath nor \xspace. What's the advantage of typing

\documentclass{article}
\usepackage{amsmath,braket}
\newcommand\transone{\ket{2,2} \rightarrow \ket{1,1}}
\newcommand\transtwo{\ket{1,1} \rightarrow \ket{2,0}}
\newcommand\transfull{\ket{2,2} \rightarrow \ket{1,1} \rightarrow \ket{2,0}}
\newcommand\ground[1]{\ket{\text{#1}}}
\newcommand\exited{\ground{e}}

\begin{document}
We have $\transone$ and $\transtwo$ that take
us to $\transfull$ and finally to $\ground{x}$
to end with $\exited$.

\end{document}


without the \$ signs? I see none, whereas I see advantages in using them. For instance, they stand better when syntax coloring is used

Just to show another strategy, here's one with xparse:

\documentclass{article}
\usepackage{amsmath,braket,xspace}
\usepackage{xparse}

\ExplSyntaxOn
\NewDocumentCommand{\newmathcommand}{m}
{
\cs_if_exist:NTF #1 { \gobblenewmathcommand{#1} } { \donewmathcommand{#1} }
}
\NewDocumentCommand{\gobblenewmathcommand}{ moom }
{
\msg_error:nnn { newmathcommand } { already-defined } { #1 }
}
\NewDocumentCommand{\donewmathcommand}{ mO{0}om }
{
\IfNoValueTF{#3}
{ \newcommand{#1}[#2]{ \ensuremath{#4}\xspace } }
{ \newcommand{#1}[#2][#3]{ \ensuremath{#4}\xspace } }
}
\msg_new:nnnn {newmathcommand}{already-defined}
{Control~sequence~#1~already~defined.}
{The~control~sequence~#1~is~already~defined,~I'll~ignore~it}
\ExplSyntaxOff

\newmathcommand\transone{\ket{2,2} \rightarrow \ket{1,1}}
\newmathcommand\transtwo{\ket{1,1} \rightarrow \ket{2,0}}
\newmathcommand\transfull{\ket{2,2} \rightarrow \ket{1,1} \rightarrow \ket{2,0}}
\newmathcommand\ground[1]{\ket{\text{#1}}}

\newcommand\exited{\ground{e}}

\begin{document}
We have \transone and \transtwo that take
us to \transfull and finally to \ground{x}
to end with \exited.

\end{document}

• I see your point about the advantages and I will take it into consideration. But the question was also about how to do the passing and you solved my problem nicely with the xparse package. However Lehmke's solution was really neat, so I accepted his answer and voted yours on up. Thank you for supplying an alternative and pointing out the disadvantage. – Theis Dec 7 '13 at 14:56