[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:
> > 
> >  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.
> > 
> > BTW, is it that hard to automatically translate ^^-notation to 8-bit
> > notation inside the AUC-TeX?
> 
> The problem is that it is wrong.  If I have something like
> 
>   You can use \verb+^^I+ to produce a TAB character.
> 
> then this translation should not happen.  If I do this sort of
> translation from the log file, then I don't get a string from the
> error message context suitable for searching in the source text, since
> it is completely unknown whether ^^I or a TAB character was actually
> typed.  I would then have to convert each ^^ occurence into a regular
> expression like \(?:\^\^I\|	\).  And then we have different ^^
> conventions to cater for in connection with Omega and stuff.

Compare this with your reply to Taco Hoekwater:

> > The user *did not* input the character corresponding to ^^J, but the
> > 6 characters comprising the string "\delta". The fact that someone
> > \mathcode-ed the character ^^J to mean the same thing as the
> > \mathchardef named \delta should not have an effect on the printing
> > of the control sequence "\delta".
> 
> There is no such control sequence.  This is the output from an
> overfull hbox message.  It contains only nameless characters.
> Whether they were produced by \mathcode, \char, \delta, whatever is
> not known anymore.

You argue that it's not possible to "go back" to \delta once it
reached TeX's stomach (which is quite true); I see no major difference
between this "loss of connection to original input" and the same loss
of connection to original input which occurs in e.g. \verb+^^I+: once
TeX have read the input, and converted it to tokens, the connection to
the original input is lost.

You also wrote:

> It has been an uphill battle all the way to butcher TeX
> implementations and locales into putting out ü as ü on the terminal.

If one uses inputenc-like approach, then the document may have
contained the character ü in some input encoding (it may even have
been represented by several bytes in case of utf-8 input encoding),
and once this character reaches the TeX's stomach, the ü ends up as a
completely different thing compared to what it may have been in the
original document.

And TeX may output to terminal in two "fundamentally" different
situations:

* unprocessed text (in the original input encoding) as it appears in
  the document, when TeX shows error context lines

* text from stomach e.g. when printing "overfill hbox" messages

There is nothing which can guarantee that the encodings of the
characters in input encoding (in error context lines messages) match
encodings of characters in TeX's internal representation.

So, even if TeX will output ü in 8-bit form to the terminal, it will
ABSOLUTELY not help AUC-TeX, because this character absolutely may
have no relation to letter ü.

Best,
v.