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

[Vladimir Volovich]

Hi!

David Kastrup wrote:

> Vladimir Volovich <vvv at vsu.ru> writes:
> > "DK" == David Kastrup writes:
> > 
> >  >> Or at least, TeX's output to *terminal* should honor the locale's
> >  >> isprint() properties. All other output (to log files, \write,
> >  >> \special, etc) MAY use 8-bit, if one wants to, but there's no
> >  >> reason to insist on "pure 8-bit" for output to *terminal*.
> > 
> >  DK> You mean, like AUCTeX which correlates the output of error
> >  DK> messages on the terminal with input lines?
> > 
> >  DK> Sorry, but when TeX is running inside of a TeX shell (writing
> >  DK> into a pipe or pseudo terminal) there are valid reasons for
> >  DK> wanting 8bit throughput.  So while we don't want a _default_
> >  DK> print-through setting probably, we at least want an option to
> >  DK> have the terminal output go through.
> > 
> >  DK> It is not sufficient here to just have the log file work out: if
> >  DK> I am using TeX in interactive mode, it is the terminal messages
> >  DK> that I have to analyze since they are up to date and flushed.
> > 
> > Shouldn't you then better have correct locale (LC_CTYPE) setting on
> > your terminal, instead of unconditionally writing binary characters
> > onto terminal?
> 
> LC_CTYPE is not a terminal setting,

Certainly, it's a locale setting, and user is supposed to set the
locale correctly while working in the terminal, in particular to
properly define which characters are printable.

Otherwise, if we ignore the locale setting when pringing to terminal,
we can get unreadable text and/or risk to change the terminal settings
in weird way, as happened in the case which opened thos thread.

> and you tell me what a correct LC_CTYPE setting for Windows, MacOSX,
> HP/UX, Linux, Solaris in various versions for a document including
> subchapters by different people written in utf8, latin1 and applemac
> input encoding would be, even if we stipulated that we wanted to
> goof around with the environment in the first place.

LC_CTYPE is independent of the encoding in which the document is
written. It's the property of the user's system (and depends, in
particular, on the character set acceptable on his terminal).

The TeX document which is being processed can be in completely
different encoding (e.g. it may come from other person who uses
another encoding or language), and has nothing to do with user's
locale.

The point is that TeX when writing to terminal should not print
unprintable characters for that particular terminal (doing otherwise
results in unreadable characters or messed-up terminal settings). And
information about printability of characters is contained in locale
settings.

> > And what is the point to have "full 8-bit output" to terminal, even
> > for all codes less than 32?
> 
> ^^I is a valid input character.

Looking at tex.web, we see some arguments:

==================
@ The first 128 strings will contain 95 standard ASCII characters, and the
other 33 characters will be printed in three-symbol form like `\.{\^\^A}'
unless a system-dependent change is made here. Installations that have
an extended character set, where for example |xchr[@'32]=@t\.{\'^^Z\'}@>|,
would like string @'32 to be the single character @'32 instead of the
three characters @'136, @'136, @'132 (\.{\^\^Z}). On the other hand,
even people with an extended character set will want to represent string
@'15 by \.{\^\^M}, since @'15 is |carriage_return|; the idea is to
produce visible strings instead of tabs or line-feeds or carriage-returns
or bell-rings or characters that are treated anomalously in text files.
==================

And what about most of the other characters with codes less than 32?
what is the point in writing them in "binary" form to the terminal?

Best,
v.