bug-auctex
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21825: 2015-10-04; utf8 and latin1 coding problem in GNU emacs, Xema


From: David Kastrup
Subject: bug#21825: 2015-10-04; utf8 and latin1 coding problem in GNU emacs, Xemacs is fine
Date: Wed, 04 Nov 2015 16:50:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Uwe Brauer <address@hidden> 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.

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

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.

Documentation:
Mapping from LaTeX encodings in "inputenc.sty" to Emacs coding systems.
LaTeX encodings are specified with "\usepackage[encoding]{inputenc}".
Used by the function ‘latexenc-find-file-coding-system’.

You can customize this variable.

Value: (("ansinew" . windows-1252)
 ("applemac" . mac-roman)
 ("ascii" . us-ascii)
 ("cp1250" . windows-1250)
 ("cp1252" . windows-1252)
 ("cp1257" . cp1257)
 ("cp437de" . cp437)
 ("cp437" . cp437)
 ("cp850" . cp850)
 ("cp852" . cp852)
 ("cp858" . cp858)
 ("cp865" . cp865)
 ("latin1" . iso-8859-1)
 ("latin2" . iso-8859-2)
 ("latin3" . iso-8859-3)
 ("latin4" . iso-8859-4)
 ("latin5" . iso-8859-5)
 ("latin9" . iso-8859-15)
 ("next" . next)
 ("utf8" . utf-8)
 ("utf8x" . utf-8))

[back]


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

-- 
David Kastrup





reply via email to

[Prev in Thread] Current Thread [Next in Thread]