[tex-k] Possible Bug in The TeXbook

[Karl Berry]

    If "right" means the direction opposite to the left, 

It does, but David Fuchs points out that The TeXbook is actually correct
in this. See his lengthy explanation below.

IMHO it is one of the more confusing passages in The TB, but it's also
hard to see how it could be notably improved without adding several
lines of explanations/examples/diagrams, and Don would not want to do
that, given that he does not want to change page breaks unless
absolutely required ... --best, karl.


Date: Wed, 6 Nov 2019 18:18:33 +0000 (UTC)
From: David Fuchs

Well, I agree that a few more (or different) words could have been used
here to make it more clear as to the real motivation behind this feature
is (I certainly puzzle over it at least once a decade, before I "get it"
again), but "the opposite of left" is the proper interpretation of both
cases of "right" here. Thus, Sebastian is wrong about "before the
replacement text;" it really is "after" / "on the right". (This is
probably best seen by the example a few paragraphs down...)

In the syntax on p.203,
  \def<control sequence><parameter text>{<replacement text>} 
and the subsequent descriptions of <parameter text> and <replacement
text> and how parameters are parsed, the idea of this feature is that
you might want a "{" to mark the end of the last "delimited parameter"
when you invoke your macro.

But there's no way to put a "{" anywhere in your "<parameter text>",
never mind at the end, so the magic incantation "#{" means "this is both
an indication of the end of the <parameter text> and the beginning of
the <replacement text> (just as if there were an unadorned "{" here),
but also an indication that when this macro is actually called, the
parsing of the final parameter should continue up to the next "{"
character in the input stream, just as if the <parameter text> had been
stored away with a real "{" at the end to represent a character constant
that delimits a "delimited parameter".

But it's also extra-magical in that when we call this macro, we don't
really want to consume that actual "{" in the input stream that delimits
the final parameter.

Now, here's where the documentation gets weird. You'd think it would say
"so, in this special "#{" case, the rules above about consuming the
matching delimiter character when parsing an actual parameter don't
apply" but instead it says "... behave as if the { had been inserted at
the right end of ... the parameter text..." which implies that it does
get consumed; but then it fixes this by effectively adding it back with
"[behave as if the { had been inserted at the right end of] ... the
replacement text," which is in exactly the spot that the consumed one
came from (since the replacement text gets inserted just before the
subsequent input from the main input stream, just after the consumed
left brace).

Well, that's kind of wordy and formal; an example is better. In the
\def\a#1#{\hbox to #1} example in the paragraph in question on p.204,
when parsing \a3pt{x}, parameter #1 is parsed as "3pt" because that's
everything up to but not including the first left brace in the
subsequent text.

But that { gets consumed by the extra left brace at the right end of the
parameter text and the rules of matching characters for delimited
parameters. Not to worry! The replacement text, which is "\hbox to #1"
by the normal rules, is treated as if it has an extra left brace at its
right end, so the replacement text becomes effectively "\hbox to #1{"
which expands to "\hbox to 3pt{" which is good, since the subsequent
input text is "x}" and we end up with "\hbox to 3pt{x}" which is what we
want.

Perhaps Sebastian was thinking of "... to the left of the subsequent
text in the input," which is how I always want to think of it, and get
myself initially confused each time.

There's probably a better way to say what I just said here, too. I bet a
diagram would help immensely. -drf