[tex-k] Wrong fix of bug S950 in TeX (and MF)

[Igor Liferenko]

Hi,

Here's the transcript of the interactive session with current TeX in TeXLive.
As you see, the current fix of bug S950 does not change TeX's behavior
in any way
(i.e., if you run such session with and without the fix, you get the
same behavior).
======================================
$ tex h
This is TeX, Version 3.141592653 (TeX Live 2022/dev/Debian) (preloaded
format=tex)
(./h.tex
! Undefined control sequence.
l.1 \ERROR

? I\MISTAKE V
! Undefined control sequence.
<insert>   \MISTAKE
                    V
l.1 \ERROR

? ?
Type <return> to proceed, S to scroll future error messages,
R to run without stopping, Q to run quietly,
I to insert something, E to edit your file,
1 or ... or 9 to ignore the next 1 to 9 tokens of input,
H for help, X to quit.
? e
You want to edit file h.tex at line 1
No pages of output.
Transcript written on h.log.
======================================

The correct fix is this:

    @x
    "E": if base_ptr>0 then
    @y
    "E": if base_ptr>0 then if name<>0 then
    @z
    @x
    if base_ptr>0 then print("E to edit your file,");
    @y
    if base_ptr>0 then if name<>0 then
      print("E to edit your file,");
    @z

Now the behavior becomes as intended:
======================================
$ tex h
This is TeX, Version 3.141592653 (TeX Live 2022/dev/Debian) (preloaded
format=tex)
(./h.tex
! Undefined control sequence.
l.1 \ERROR

? I\MISTAKE V
! Undefined control sequence.
<insert>   \MISTAKE
                    V
l.1 \ERROR

? ?
Type <return> to proceed, S to scroll future error messages,
R to run without stopping, Q to run quietly,
I to insert something,
1 or ... or 9 to ignore the next 1 to 9 tokens of input,
H for help, X to quit.
? e
Type <return> to proceed, S to scroll future error messages,
R to run without stopping, Q to run quietly,
I to insert something,
1 or ... or 9 to ignore the next 1 to 9 tokens of input,
H for help, X to quit.
?
======================================

MF is similar.

Best regasds
  Igor

P.S.
BTW, the problem of the font definitions running together in dvitype
is not mentioned on
this page:
    https://www.tug.org/texmfbug/newbug.html