It seems that if I \let\amp&, the alignment tab & can be replaced by \amp everywhere (e.g., in the preamble and in the body of an \halign). It is also possible to make the character & active, and give it the same meaning by \catcode`\&=13 \let&\amp. It seems that that active & which has been let to the alignment tab & can be used wherever an alignment tab & was used.

This idea is quite general: we can define macro which takes a character as its argument, lets its active version to itself (with its current catcode), and finally makes the character active. This uses an \lccode trick, described by Phillipe Goutet.

  \lowercase{\endgroup \let~#1}%

Here is an example to show that this operation does not break most uses I can think of for $, &, etc. In particular, $$...$$ is still recognized, and macro parameters too.

\activate &
\halign{#&#\cr a&b\cr}

\activate $    \activate ^    \activate _
$$ x^2_2 + y^2_2 $$

\activate #
\myshow #    

So my question is: "what are the drawbacks of this approach?" It allows a fix for peeking ahead with \futurelet in alignments.

  • 5
    Might be one for c.t.t: I wonder what the real experts think!
    – Joseph Wright
    Commented Feb 23, 2011 at 22:23
  • @Joseph: I remember you mentionning somewhere an "outstanding issue with \peek_ahead_... in (nested?) alignments". Could you please point me to a description of that? It would make my c.t.t. post more complete. Commented Feb 24, 2011 at 12:48
  • The best I can offer at the moment is the siunitx source. Take a look at \siunitx_table_collect_get:, and using \peek_catcode_ignore_spaces:NTF (with appropriate values) in place of the 'by hand' version I have there at the moment. Result: lots of errors, and I think at some stage disaster (it's been a while since I tested this).
    – Joseph Wright
    Commented Feb 25, 2011 at 22:27
  • @Joseph: thank you. To prevent \futurelet from triggering the construction of a cell if it hits a & or \cr, we normally use: \safebegin\futurelet\@let@token\macro, where \safebegin is \iffalse{\fi\ifnum`}=0\fi and \macro starts with a \safeend, defined as \ifnum`{=0}\fi. But this breaks when put in an \halign preamble (as in siunitx). Commented Feb 26, 2011 at 5:34
  • Minimal example: set \def\safeboxalign{\safeend\vbox\bgroup\halign\bgroup##} and use the \safebegin and \safeend above. Then \halign{#\cr \safebegin \futurelet \dummy \safeboxalign \cr ABC\cr \egroup \egroup \cr} works. But now, move the \safebegin ... \safeboxalign to the preamble of the main \halign (before #). The result, \halign{\safebegin \futurelet \dummy \safeboxalign #\cr \cr ABC\cr \egroup \egroup \cr}, breaks horribly. --- OTOH, redefining \cr and an active & seems to work. Commented Feb 26, 2011 at 5:37

2 Answers 2


One drawback of this approach is that earlier defined macros which have these special characters in their parameter text will stop working. Good written packages will change the catcode to this characters to a pre-defined value before calling such macros, but you never know. Also sometimes this isn't doable like when the macro should be fully expandable.

In general your redefinition should work identical to the original in every context where TeX is executing the found tokens, e.g. inside normal boxing mode, but will result in different results in scanning mode.

  • my plan would be to have that at the very start of the TeX run. Then all delimited macros would be defined with an active & as a delimiter. Your answer still holds very true for braces: implicit braces will never be a good alternative to explicit ones. --- Another point is that I wouldn't call the preamble of an \halign "normal boxing mode": it is definitely scanning (in some weird way). Commented Mar 1, 2011 at 19:07
  • @Bruno: I was talking about the & which separate the actual cells. The reading of the preamble is different. That is moer scanning mode. Note that & and \cr are actually catched by the TeX parser and expanded even when TeX isn't in expanding mode, which explains why \futurelet doesn't work like Hendrik expected. Defining & like you do effective hides the token from the parser until it is really expanded. Commented Mar 1, 2011 at 19:16
  • 1
    In \let\amp& \halign{(#)\amp [#]\cr ab\amp cd\cr}, the \amp is seen both in the preamble and in the body. The parser behaves in this situation in a way similar to how conditionals are treated: \def\amp{&} would not be seeen in the preamble. Commented Mar 1, 2011 at 19:48

Such active characters let to the original character work exactly the same as the original character, except in delimited arguments from macros defined prior to the category code change, and within \csname...\endcsname constructions.

{\delimited...&} % BOOM: & is not seen
\csname &\endcsname % BOOM

The second case comes up when trying to add \let\amp& etc to the beginning of a LaTeX file which uses amsmath. That's due to \newhelp using a \csname...\endcsname construction to store help messages, one of which contains &. That could be avoided by redefining & locally inside \newhelp:

  \newtoks#1#1\expandafter{\csname #2\endcsname}% old def of \newhelp

or by letting it be active but only equal to an alignment tab after \begin{document} since alignment tabs are only useful inside tables, none of which typically appear outside the document:

\let&\alignmenttab % macro!
% ...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .