Re: new beta: 2.96.2

Olaf Weber <[email protected]> writes:

> David Kastrup writes:
> 
> > In the case of broken or inconsistent locales, about the only
> > workable alternative was to specify --translate-file=cp8bit for
> > every call of TeX/LaTeX.
> 
> > The way the description of the new behavior sounds, not even this
> > will help against systems with broken locale settings now: the TeX
> > error messages will refuse to use the encoding of the input files
> > even then.
> 
> > Please tell me if I misunderstood anything.
> 
> As far as I can tell, using cp8bit.tcx didn't help with broken locales
> in the previous version either.

I might have missed a few beats with regard to Web2C.  And I've always
been able to pummel my own locales into submission rather than revert
to translation files.

But I know that we have recommended the --translate-file=cp8bit as a
last resort to people in the past when all other options have failed.
Sounds like this escape path is no longer open.

Anyway, with AUCTeX the interpretation of the byte stream coming from
the terminal output is done with the coding system that the original
file has been in.  In this case, I really want to have the terminal
output messages be in the same encoding as the input file, regardless
of what the system locale happens to be.  Perhaps some environment
variable might be used for indicating this mode of completely
transparent output messages?

It would appear to be the "natural" choice for usage inside of TeX
shells, and it would mean that we don't have to hand-hold people
through configuring a workable 8bit-locale even when the actual
locale is completely irrelevant for the TeX shell operation.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum