Re: Emacs 22.1.90 can't save chinese-gb2312 file

[Kenichi Handa <handa@ni.aist.go.jp>]

In article <ebaf065f0801312030x70d3fb7aj96368c58cb8763c7@mail.gmail.com>, "Zhang Wei" <id.brep@gmail.com> writes:

> On 2/1/08, Zhang Wei <id.brep@gmail.com> wrote:
> > When I save a file in gb2312 coding system, I got the following
> > compliant, all of the chinese punctuation characters can't be encoded
> > with gb2312:
> > ------------------------------------------------------------------------------
> > These default coding systems were tried to encode text
> > in the buffer `test':
> >  chinese-iso-8bit
> > However, each of them encountered characters it couldn't encode:
> >  chinese-iso-8bit cannot encode these: ， 。 、 ？
> >
> > Click on a character (or switch to this window by `C-x o'
> > and select the characters by RET) to jump to the place it appears,
> > where `C-u C-x =' will give information about it.
> >
> > Select one of the safe coding systems listed below,
> > or cancel the writing with C-g and edit the buffer
> >   to remove or modify the problematic characters,
> > or specify any other coding system (and risk losing
> >   the problematic characters).
> >
> >  utf-8 utf-16 utf-16 utf-16 utf-16be utf-16le iso-2022-7bit
> > --------------------------------------------------------------------------
> > C-u C-x = gives:
> > --------------------------------------------------------------------------
> >  character: 。 (302786, #o1117302, #x49ec2, U+3002)
> >    charset: mule-unicode-2500-33ff (Unicode characters of the range
> > U+2500..U+33FF.)
> >  code point: #x3D #x42
> >     syntax: w  which means: word
> > buffer code: #x9C #xF2 #xBD #xC2
> >  file code: not encodable by coding system chinese-iso-8bit
> >    display: by this font (glyph code)
> >     -outline-Courier
> > New-normal-r-normal-normal-13-97-96-96-c-*-iso10646-1 (#x3002)
> >
> > [back]
> > --------------------------------------------------------------------------
> >

> This bug crept in due to the changes of w32term.c since 2007-12-12, I
> think, when I revert the changes of this file, the bug is gone.

Are you sure?  It's quite surprising that the code in
w32term.c affects encoding of characters.

---
Kenichi Handa
handa@ni.aist.go.jp