Re: locale ISO-8859-15, UTF-8 and mail...

[Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann)]

fabien@tzone.org (Fabien Niñoles) writes:

>>>>>> "Kai" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:
>
>     Kai> I don't understand.  What does `W M c' have to do with
>     Kai> latinX-disp.el?
>
> Nothing.  There seems to have two "bugs" here:
>
> 1- Gnus seems to defined it's own buffer-display-table instead of
> using the standard-display-table.  Since latinX-disp.el simply
> modify the standard-display-table to be effective, it doesn't seems
> to work in gnus (at least v5.9.0 that I used here).

What does Gnus use that display table for?  Maybe it's used for
something useful.  But maybe Gnus should inherit from the standard
display table, and then frobbing that first with latinX-disp should
do the trick.

> 2- I isolate the other bug (the \201 or \216 character add before
> every high-bit set character in multibyte environment) to a bug in
> the coding-system.  To test it just evaluate this:
>
> (decode-coding-string "élève" 'iso-8859-1) => "\216él\216ève" in latin-1 environment.

The documentation for decode-coding-string says that it is required
for the string to be encoded in the given coding system.  Maybe your
string is in iso-8859-15 and not iso-8859-1.  If you give
decode-coding-string some Japanese and tell it to decode as
iso-8859-1, it won't be surprising that you get garbage, either.

\216\151 is the internal Emacs representation (the Mule encoding) of
that accented character in Latin-9.  \201\151 would be the internal
representation of the same character in Latin-1.

You can type C-u C-x = on the é character to verify whether it is in
iso-8859-1.

Hm.

Hm.

Also, I think that the function has been misapplied.
decode-coding-string and encode-coding-string are for converting
between external and internal representations.  So,
(decode-coding-string X 'iso-8859-1) takes a sequence X of bytes
encoded as iso-8859-1 and returns a string encoded in Emacs' internal
encoding.  But you were passing not a sequence of bytes encoded in
iso-8859-1, you were passing a Lisp string encoded in Emacs' internal
encoding.  And that encoding happens to use \216\151 for the é
character, so that's what you get...

Maybe you can use vector to create a proper sequence of bytes.
Or you get the bytes from an I/O operation (input, to be specific).

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)