# [texhax] Some puzzling TeX

Rod Harries rod at harries.net.nz
Thu Feb 17 03:50:28 CET 2011

On 17/02/2011, at 1:50 PM, Stephen Hicks wrote:

<snip>

> What's happening here?  It turns out that spaces are particularly
> tricky in TeX.  I don't have my TeXBook on me right now, but the way
> the \let primitive is defined, it allows an optional "=" in between
> the token it's assigning to and the token it's assigning from.  This
> optional "=" may be surrounded by any number of spaces.  So when you
> simply say "\let\@sptoken= %" it's still waiting for the token to
> assign to \@sptoken, and the next non-space it encounters will be it
> (hence the \relax on the next line).  In the case of "\def\@sptoken{
> }" that's completely different.  This is defining a macro, which has a
> completely different category code than a space.  The point here is
> that the author presumably wants \@sptoken to really be in every way a
> space, probably so he can use \ifcat to check if something else has
> the same catcode.  But the \def'ed \@sptoken (and all normal control
> sequences) has catcode 16, rather than 9.
>
> So what is this actually doing?  It defines the macro to actually
> contain the space.  Moreover, when control characters (i.e. \: rather
> than \x) are expanded, they don't eat any following spaces.  So then
> "\: " expands to \let\@sptoken=<space><space>, which normally is
> impossible to achieve since TeX eats adjacent spaces when it first
> tokenizes the file.

As usual my problem was caused by not reading the TeXBook carefully enough. I knew that = can be preceded by optional spaces,
but hadnt noticed that in let assignments it can be followed by an optional space.

It is interesting to experiment with \ifx and various things which might be equivalent to spaces
to see what happens.

Thanks to those who replied. I think Stephen's response took the prize.

Rod Harries