Re: standard-display-european

[Reiner Steib]

On Sat, Aug 21 2004, Richard Stallman wrote:

>     `standard-display-european' is obsolete (IIRC at least since Emacs
>     20.7).   You should probably use (set-language-environment "Latin-1")
>     or omit it completely (Emacs does the right thing when your locales
>     are set up correctly).
>
> It is only semi-obsolete.  It is still supposed to work.
> Many init files used to use it, and I would guess many still do.

My impression is that most people don't really want
`standard-display-european'.  They only have it in their init files
because it was useful (for Europeans) in Emacs 19 (or earlier?).
There were many reports in newsgroups during the last years about
"Emacs doesn't treat Umlaut characters correctly"; IIRC all were
perfectly happy after removing `standard-display-european' from their
init file.

> Therefore, we should still fix the crash, and also this bug:
>
>     `standard-display-european' leads to incorrect behavior of Gnus.
>
> Can you fix this one?

I'm afraid I can't (therefore Cc-ing the Gnus list; maybe someone has
an idea).  I will try to provide more details:


* Is this behavior in Emacs (doesn't involve Gnus) correct?

- Start: emacs -q -no-site-file -eval '(standard-display-european t)'

- Display the HELLO file (`C-h h')

- Copy the line "German (Deutsch) Guten Tag, Grüß Gott" to the kill
  ring (using `M-w').  Do `M-x describe-char RET' on the "ü" ==> [1].
 
- Create a new buffer, yank the line and do `M-x describe-char RET' on
  the "ü" ==> [2].  The char is eight-bit-graphic now instead of
  Latin-1.  It is also considered as "syntax:[...] whitespace" which
  leads is not useful: `M-f' stops at each non-latin char, ispell and
  flyspell fail, ...


* With Gnus:

When using Gnus in with (standard-display-european t), the char also
is eight-bit-graphic.  When quoting such an article (or yanking the
line from HELLO), Gnus will prompt the user for a charset on sending
("Charset used in the article:") and many users pick a random value.
IIRC the resulting article may also be encoded incorrectly even when
answering "iso-8859-1", but I'm not able to reproduce this at the
moment.

Bye, Reiner.

[1]
,----[ HELLO ]
|   character: ü (04374, 2300, 0x8fc, U+00FC)
|     charset: latin-iso8859-1
|            (Right-Hand Part of Latin Alphabet 1 (ISO/IEC 8859-1): ISO-IR-100.)
|  code point: 124
|      syntax: w        which means: word
|    category: l:Latin  
| buffer code: 0x81 0xFC
|   file code: ESC 0x2C 0x41 0x7C (encoded by coding system iso-2022-7bit-unix)
|     display: by this font (glyph code)
|      -Misc-Fixed-Medium-R-Normal--14-130-75-75-C-70-ISO8859-1 (0xFC)
`----

[2] (I have replaced the eight-bit-graphic `\373' in this mail)

,----[ *latin* ]
|   character: \374 (0374, 252, 0xfc)
|     charset: eight-bit-graphic (8-bit graphic char (0xA0..0xFF))
|  code point: 252
|      syntax:          which means: whitespace
| buffer code: 0xFC
|   file code: not encodable by coding system iso-latin-1
|     display: by display table entry [?\374] (see below)
| 
| The display table entry is displayed by these fonts (glyph codes):
| \374: -Misc-Fixed-Medium-R-Normal--14-130-75-75-C-70-ISO8859-1 (0xFC)
`----
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/