I want to make the code shorter. I defined the following pair of macros:

\def\b*{\begin{align*}}
\def\e*{\end{align*}}


My point is that I saw this in a document, with

\def\b*{\begin{eqnarray*}}
\def\e*{\end{eqnarray*}}


instead. The first pair of macros do not compile (on sharelatex.com), and the second one does. Why?

• This is a documented restriction of the ams alignments, the \end needs to be explicit Also why the * ? – David Carlisle Apr 11 '14 at 23:15
• Are you not using an editor with auto-completion? – Sigur Apr 11 '14 at 23:16
• @DavidCarlisle: the * was in the original document I found. Is there any way to get what I want (define a macro and avoid equnarray?) – mookid Apr 11 '14 at 23:17
• @Sigur: I do, but I prefer having a shorter code (I really like the code in which I found the macro). – mookid Apr 11 '14 at 23:18
• \def\b* defines \b not \b* (but defines it to require a *) amsmath is open source so you can change anything but basically no, it is not intended that you hide the environment syntax. – David Carlisle Apr 11 '14 at 23:24

The technote document explains why this kind of shorthand definitions will fail:

## 6   Why can’t I use abbreviations for \begin{align} ... \end{align}?

Authors often like to use abbreviations such as \beq \eeq for . For some environments defined by the amsmath package, such as align, gather, multline, and others of the same general type, this does not work: An attempt to define \bal \eal as shorthand for \begin{align} \end{align} will fail with a puzzling error message. This has to do with unfortunately nontrivial technical complications: the given environments must read their contents as a delimited macro argument because they do multipass processing of the contents using algorithms inherited from Spivak’s amstex.tex. The obvious solution-substitution of different algorithms that do box shuffling instead of token shuffling for the multipass calculations-would require rewriting these display environments from the ground up; while that is a worthy goal, it was beyond the original scope of the AMS-LaTeX project. Work is under way on an auxiliary package called breqn that addresses not only this problem but a number of others; at the time of this writing, however [September 1999] it has only progressed as far as a beta release.

Some workarounds:

• \def\bal#1\eal{\begin{align}#1\end{align}}
• Define \newcommand{\env}[2]{\begin{#1}#2\end{#1}} and then use \env{align}{...}
• +1 for superior line-breaking over David's answer. ;) – Sean Allred Apr 12 '14 at 0:10
• Nice! Is there any chance to get it allowed in the future? – Sigur Apr 12 '14 at 0:31
• @Sigur I'm afraid that is a question for the AMS team. barbara beeton could surely provide an informed answer for your question (but I strongly suspect that the answer will be "no"). – Gonzalo Medina Apr 12 '14 at 0:33
• @GonzaloMedina, me too. :-) – Sigur Apr 12 '14 at 0:40
• @Sigur -- yes, the answer is "no". if real bugs aren't addressed in a timely manner, what do you think is the likelihood of a major design change being undertaken? – barbara beeton Apr 12 '14 at 5:00

The restriction of the AMS alignments that they may not be hidden behind command forms is documented on page 28 of the amsmath guide (texdoc amsmath ) Actually the restriction is better described in the technical notes (texdoc technote) as shown in the other answer.

The names chosen here are particularly dangerous as using \def you lose the warning that you would have had from the correct LaTeX syntax \newcommand that you were over-writing the standard accent command \b.

• Perhaps you could include the link to the technote document (perhaps even the image) in your answer so I can delete mine? – Gonzalo Medina Apr 11 '14 at 23:48
• @GonzaloMedina I thought it was in technote but I typed texdoc texnotes with an s and got a different document, so I made do with the reference in amsmath guide:-) Leave your answer and I'll cross link:-) – David Carlisle Apr 11 '14 at 23:50