From owner-ntemacs-users@cs.washington.edu  Wed Oct 14 05:48:53 1998
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "14" "October" "1998" "13:26:00" "+0100" "Andrew Innes" "andrewi@harlequin.co.uk" nil "45" "Re: NT Emacs, message-mode and 8 bit characters..." "^From:" nil nil "10" nil nil nil nil]
	nil)
Received: from joker.cs.washington.edu (joker.cs.washington.edu [128.95.1.42]) by june.cs.washington.edu (8.8.7+CS/7.2ju) with SMTP id FAA15204 for <voelker@june.cs.washington.edu>; Wed, 14 Oct 1998 05:48:52 -0700
Received: from trout.cs.washington.edu (trout.cs.washington.edu [128.95.1.178]) by joker.cs.washington.edu (8.6.12/7.2ws+) with ESMTP id FAA28799 for <voelker@joker.cs.washington.edu>; Wed, 14 Oct 1998 05:48:51 -0700
Received: (majordom@localhost) by trout.cs.washington.edu (8.8.5+CS/7.2ws+) id FAA20295 for ntemacs-users-outgoing; Wed, 14 Oct 1998 05:26:53 -0700 (PDT)
Received: from june.cs.washington.edu (june.cs.washington.edu [128.95.1.4]) by trout.cs.washington.edu (8.8.5+CS/7.2ws+) with ESMTP id FAA20291 for <ntemacs-users@trout.cs.washington.edu>; Wed, 14 Oct 1998 05:26:50 -0700 (PDT)
Received: from holly.cam.harlequin.co.uk (holly.cam.harlequin.co.uk [193.128.4.58]) by june.cs.washington.edu (8.8.7+CS/7.2ju) with ESMTP id FAA12799 for <ntemacs-users@cs.washington.edu>; Wed, 14 Oct 1998 05:26:46 -0700
Received: from gpo.cam.harlequin.co.uk (gpo.cam.harlequin.co.uk [192.88.238.241])           by holly.cam.harlequin.co.uk (8.8.4/8.8.4) with ESMTP 	  id NAA06030; Wed, 14 Oct 1998 13:26:33 +0100 (BST)
Received: from gridlock.cam.harlequin.co.uk (gridlock.cam.harlequin.co.uk [192.88.238.223])           by gpo.cam.harlequin.co.uk (8.8.4/8.8.4) with ESMTP 	  id NAA29383; Wed, 14 Oct 1998 13:26:00 +0100 (BST)
Message-Id: <199810141226.NAA29383@gpo.cam.harlequin.co.uk>
In-reply-to: <u1zocjuf6.fsf@TENDLE.citrix.com> (message from John S Cooper on 	13 Oct 1998 17:30:53 +0100)
References:  <u1zocjuf6.fsf@TENDLE.citrix.com>
Precedence: bulk
X-FAQ: http://www.cs.washington.edu/homes/voelker/ntemacs.html
From: Andrew Innes <andrewi@harlequin.co.uk>
Sender: owner-ntemacs-users@cs.washington.edu
To: John.Cooper@citrix.com
CC: ntemacs-users@cs.washington.edu
Subject: Re: NT Emacs, message-mode and 8 bit characters...
Date: Wed, 14 Oct 1998 13:26:00 +0100 (BST)

On 13 Oct 1998 17:30:53 +0100, John S Cooper <John.Cooper@citrix.com> said:
>The following message is a courtesy copy of an article
>that has been posted to gnu.emacs.gnus as well.
>
>
>I recently upgraded to NT Emacs 20.3.1 and pgnus v0.34, and found that when I
>attempted to enter 8 bit latin-1 characters into my mail messages (using
>iso-acc.el), the 8th bit seemed to be getting stripped.
>
>Calling standard-display-european didn't help.
>
>The *mail* buffer modeline started "-1:" which apparently signifies the buffer
>is using a latin-1 coding system; I therefore would have expected 8 bit chars
>to be displayed properly.
>
>I was able to enter 8 bit chars into other buffers that didn't have the "-1:"
>modeline designation.
>
>After some experimentation, I finally found that adding `(set-buffer-multibyte
>nil)' to my message-mode-hook enabled me to enter 8 bit chars.

I believe the problem here is simply that the redisplay support on
Windows in 20.3 is not fully MULE aware.  The situation should be much
better in 20.4.

When MULE is enabled (and it sounds like pgnus is turning it on
specifically for its own buffers, overriding the effect of
standard-display-european which turns it off), non-ascii characters are
stored as multiple bytes in Emacs, and the display code is responsible
for interpreting the internal representation and displaying them
correctly.  In 20.3, NT-Emacs doesn't try to handle the charset property
of multibyte characters, and ends up displaying iso-latin-1 characters
as ascii (ie. with the high bit stripped, as you noticed).

If you type `C-x =' when positioned over such a character like "é" (e
with acute accent), you should see that Emacs thinks the character is
0x8e9 (0x8?? indicates iso-latin-1), even though it is displaying as the
ascii character "i" (0x69).

By calling (set-buffer-multibyte nil), you override pgnus and force MULE
off for the message buffer; with MULE off, the redisplay code works
properly.  (If you now type `C-x =' on é, the character value should be
the expected iso-latin-1 codepage value 0xe9.)

AndrewI

