Subject: bug#21825: 2015-10-04; utf8 and latin1 coding problem in GNU emacs, Xemacs is fine

From: Uwe Brauer <[email-masked]>
Date: Wed, 04 Nov 2015 16:36:09 +0000

>>> "David" == David Kastrup <[email-masked]> writes:

   > Uwe Brauer <[email-masked]> writes:
   >> Hello
   >> 
   >> The following problem only occurs in GNU emacs 24.5 or 25.0.50.
   >> 
   >> I have two files:
   >> 
   >> The first is saved in latin-1 but its header state
   >> \usepackage[utf8]{inputenc}
   >> 
   >> And the other is the other way around
   >> saved in UTF8 header is 
   >> 
   >> \usepackage[latin1]{inputenc}
   >> 
   >> 
   >> Both are displayed correctly in Xemacs and but not in GNU emacs.

   > I have a hard time understanding what you mean by "displayed correctly"
   > when the display does not correspond to what LaTeX would output.

I thought, that sending the latex files would have been enough. I attach
the screenshots.

   > Why are you lying to LaTeX/Emacs about the document encoding?  And what
   > do you hope to achieve by Emacs ignoring this?

This is not on purpose of course, so this could occur if one has either
a very large header and forgets what coding has been  selected (this is lame I
know) or more realistically you have a multi file documentation and
don't recall its encoding.

However there is one thing I just have to add. Maybe I was «spoiled»
in the past by Xemacs/x-symbol behavior which displayed any coding
correctly but internally had the files saved in ascii mode. (Like
running iso-iso2tex on every save).

Of course thinking about it again, you are right. This is a bad habit.
So this is not a bug.

I could solve the issue of the wrongly displayed coding by just removing
the incorrect header and reopening the file.

BTW how else could this wrong coding be repaired? I am asking because I
have encountered similar problems in non latex files, which have been
modified by Xemacs.

   > Of course one can switch off inputenc encoding recognition, cf.

   > latex-inputenc-coding-alist is a variable defined in ‘latexenc.el’.
   > Its value is shown below.

I did not know about this. Thanks for pointing it out.

   > Documentation:

   > but in particular for telling apart various different 8-bit encodings
   > there is not much of an alternative.