Why does space matter while error-handling in plain TeX?

Question

Following Chapter 6 of The TeXbook, I analyze the errors in the story.tex file containing \errorcontextlines=0 in the beginning, and an erroneous control sequence: \centerline{\bf A SHORT \ERROR STORY}. As expected, on running tex story.tex, I get the following error:

! Undefined control sequence.
<argument> \bf A SHORT \ERROR 
                              STORY
...
l.4 \centerline{\bf A SHORT \ERROR STORY}

But then, similar to what is suggested in the ending double-dangerous section, I type the following after the ? prompt:

1. ? I\errorcontextlines=100 \oops (with space, as actually suggested in the book)
   This gives the expected follow-up prompt:

    ! Undefined control sequence.
    <insert>   \errorcontextlines=10 \oops
   
    <argument> \bf A SHORT \ERROR 
                                  STORY
    \centerline #1->\line {\hss #1
                                  \hss }
    l.4 \centerline{\bf A SHORT \ERROR STORY}
   

2. ? I\errorcontextlines=100\oops (without space)
   This gives unexpected prompt:

    ! Undefined control sequence.
    <insert>   \errorcontextlines=10\oops
   
    ...
    l.4 \centerline{\bf A SHORT \ERROR STORY}
   

(\oops is an undefined control sequence.)

Question: This seems to suggest that TeX cares about the space in the above, but this seems wrong! What is going on here?

Answer 1

When TeX is scanning for a number, the space after the digits terminates the scanning, so \errorcontextlines=10<space> is a "complete" instruction, while \errorcontextlines=10 is "incomplete", in the sense that what comes after it might change the outcome. The next token might as well be another digit, changing completely the value stored in \errorcontextlines, so TeX keeps on expanding looking for more digits or something that terminates the scanning.

You can more clearly see the order in which things happen by comparing the outcome of these two (it doesn't have to be a ? prompt):

% \test shows the value of \errorcontextlines and shows the following token
\def\test{\showthe\errorcontextlines \show}
\afterassignment\test
\errorcontextlines=10 \oops 0x
\bye

which shows:

This is TeX, Version 3.141592653 (TeX Live 2023) (preloaded format=tex)
(./test.tex
> 10.
\test ->\showthe \errorcontextlines
                                    \show
l.5 \errorcontextlines=10
                          \oops 0x
?
> \oops=undefined.
l.5 \errorcontextlines=10 \oops
                                0x
?
[1] )
Output written on test.dvi (1 page, 208 bytes).
Transcript written on test.log.

and this:

% \test shows the value of \errorcontextlines and shows the following token
\def\test{\showthe\errorcontextlines \show}
\afterassignment\test
\errorcontextlines=10\oops 0x
\bye

which shows:

This is TeX, Version 3.141592653 (TeX Live 2023) (preloaded format=tex)
(./test.tex
! Undefined control sequence.
l.5 \errorcontextlines=10\oops
                               0x
?
> 100.
\test ->\showthe \errorcontextlines
                                    \show
<to be read again>
                   x
l.5 \errorcontextlines=10\oops 0x

?
> the letter x.
<recently read> x

l.5 \errorcontextlines=10\oops 0x

?
 )
No pages of output.
Transcript written on test.log.

In the first example, \errorcontextlines is assigned 10, then \text is executed (because of \afterassignment) and shows that the following token is \oops. Then 0x is typeset to the dvi.

In the second example, TeX is still scanning for an integer when it sees \oops, then it complains that \oops is undefined (then ignores it) and resumes scanning for an integer. The 0 is seen and added to the integer, then the x is seen, which is not a valid digit, so it stops the scanning. \errorcontextlines is assigned 100, then \text shows that the following token is x. Nothing is typeset.