Console ASCII interpretation

[Warner Losh]

> You're right. The code I'm using is wrong when it is being executed
> under the console. However the fact that Eterm and xterm do what I
> want to do with my app show that I'm not the only one who needs a
> NOP ascii value. Both render the NUL ascii code as NOP. Since both
> terms are much newer than the console this indicates that they
> reflect the recent changes in software development much better.

xterm's code base pre-dates syscons by about 10 years.  While it
started out life as a clu program back in the early 1980's, but 1986
it had been recast in 'C' with X version 10.  syscons wasn't written
until about 1994 or so.  However, which one is RIGHT and which one is
WRONG is the wrong question to ask.  xterm implements a vt220 with
some other goo.  This is a different terminal emulation than syscon's
emulation, which is an old SCO console, which is akin to, but
different than MSDOS's ANSI.SYS emulation.  The point that you have
consistantly been missing is that each thing that's being emulated
treats NUL characters differently.  You are also missing the point
that NUL characters are *NOT* nops.  Get that notion out of your head.
It is false.  If nothing else, a NUL character, on a terminal line,
takes time to transmit, affecting the timing of subsequent characters.
Since both xterm and syscons are emulating some kind of terminal, this
point is relevant.

So you'd need to show that the syscons behavior is a bug by showing
that the SCO terminal emulation did things differently, because that's
what it is emulating.

xterm is getting it right for vt100/vt220 emulation, because I know
for a fact that NUL characters, on that type of terminal, did in fact
cause no cursor motions and were used for timing only.

> Keeping code simply because of historic reasons doesn't seem  too obvious
> to me. There are a lot if ways to let the user decide whether he
> prefers historic code over new code. Hence all the COMPAT options
> in the kernel.

There's no COMPAT_* option to control this stuff.  While railing
against this sort of thing may be a good point, it is irrelevant to
this discussion.

Warner