[tex-live] fwd: \delta in overfull \hboxes screws up xterm

[Olaf Weber]

Karl Berry writes:

> Guys, these are logically inconsistent requirements.  I see everyone's
> point and don't think anyone is "wrong" ... but we can't make TL fulfill
> all of this (by default).

Exactly.  Like it or not, we'll have to pick some kind of default that
we can at least live with.

> So I think the question is what takes precedence:
> 1) "clean" pure 8-bit approach.

Implementation: "-8bit" in fmtutil.cnf.

> 2) "mixed" 7.5-bit approach to terminal, 8-bit files (new implementation
>    work needed).

Which I'm not even starting on unless the clear consensus is that this
is what should be done.

> 3) "mixed" 7.5-bit approach to both terminal and files.

Implementation: "-translate-file=cp8bit" in fmtutil.cnf.  That's the
same file that is automatically included in current released TeX-live,
and makes codes 128...255 printable.

> Personally, I think writing binary codes < 32 to the terminal is the
> most important thing to avoid.  It can mess up users who are simply
> trying to do exactly has always worked and what Knuth documents. But
> that's just my opinion.  What do others think?  Thomas, Olaf, Fabrice,
> Staszek, Sebastian?

One this I'd like to observe is that on my Debian GNU/Linux system,
xterm does not exhibit this behaviour.  I believe it may be build from
different sources than the RedHat (etc) xterm, and probably has SO and
SI disabled.  On my IRIX machine, the normal winterm and xterm both
seem to ignore SO and SI.

Personally, I have seen the switch-to-and-unreadable-mess behaviour of
xterm only on Linux systems.  I do not recall ever needing it, only
being frustrated by it, and suspect that I wasn't the only one.

Has anyone encountered other terminal types that get confused like
this?

Of course, it is also possible to get TeX to spew actual ESC sequences
and mess up a terminal that way.

-- 
Olaf Weber

               (This space left blank for technical reasons.)