# Weird output of \tracingassigns with \font

Setting \tracingassigns to a positive value causes eTeX to write to the log file (and console when \tracingonline is positive) all assignments it performs. Thus, I would expect the following code to indicate that \foo is changed from undefined to select font cmr10.

\tracingonline=1
\tracingassigns=1
\font\foo=cmr10
\message{But \foo is \meaning\foo!}


However, eTeX reports

{changing \foo=undefined}
{into \foo=select font nullfont}
But \foo is select font cmr10!


Why?

-

Knuth refers to this mechanism on page 278 of the TeXbook:

\TeX\ takes precautions so that constructions like ‘\chardef\cs=10\cs’ and ‘\font\cs=name\cs’ won't expand the second \cs until the assignments are done.

\chardef\cs=63


you'll find in the log

{changing \cs=undefined}
{into \cs=\relax}
{changing \cs=\relax}
{into \cs=\char"3F}


However, apparently, the change of meaning from "select font nullfont" to "select font cmr10" is not traced and this might be a bug of e-TeX.

Why is such a precaution necessary? When TeX does

\font\foo=<filename>


it performs expansion on what follows the = sign. If \foo, for some reasons, were already defined as a macro, a code such as

\font\foo=cmr10\foo


would result in a probable disaster. So, first of all, TeX changes the meaning of \foo to an unexpandable token, precisely \nullfont. So, a following \foo token would stop expansion and the real assignment can be performed.

In the case of \chardef\cs=63 we are in the same situation:

\chardef\cs=63\cs


would be disastrous if, say, we had \def\cs{1} before. So TeX first assigns to \cs the meaning of \relax and can perform the assignment without worrying that \cs might be expanded. When TeX reads \cs again, it already has the meaning assigned by \chardef.

## Update

This is an e-TeX bug due to one of Don's typical (and at the time valid) optimizations. The eTeX change file implements \tracingassigns by interfacing in the procedure eq_define() in module §277 and the assignment of "nullfont" in §1257 is done using this procedure. However, (and this is Don's way of saving a a few computer cycles :-) the second assignment is done through a direct call to the procedure equiv() which is normally not used for assignments as it only changes a pointer but doesn't set the "type" (which is of course still "selectfont").

-
Should we report that bug somewhere? It doesn't seem that important, and is probably quite tough to fix. –  Bruno Le Floch Jan 10 '12 at 22:52
@BrunoLeFloch I don't think that Peter Breitenlohner would even try fixing this, as it seems to involve pretty deep workings of TeX. My impression is that this might break passing the trip test. –  egreg Jan 10 '12 at 23:16
@egreg I doubt that this is difficult to fix, it would just need some adjustment to §1257 duplicating what normally is done by \$277. It might be worth pointing out to Peter at least. As to the trip test, this is part of the extension code that e-TeX provides so that will anyway not pass the trip test and if the extensions are not enabled then there should be no difference as that code would then be bypassed like the code in §277. –  Frank Mittelbach Jan 13 '12 at 11:07