GNU bug report logs - #23814
24.5; bug of hz coding-system

Previous Next

Package: emacs;

Reported by: ynyaaa <at> gmail.com

Date: Tue, 21 Jun 2016 12:23:02 UTC

Severity: normal

Found in version 24.5

Fixed in version 26.1

Done: Glenn Morris <rgm <at> gnu.org>

Bug is archived. No further changes may be made.

Full log

Message #23 received at 23814 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: handa <at> gnu.org
Cc: ynyaaa <at> gmail.com, 23814 <at> debbugs.gnu.org
Subject: Re: bug#23814: 24.5; bug of hz coding-system
Date: Sat, 09 Jul 2016 14:20:19 +0300

Ping!  Could you please comment on this issue?

> Date: Wed, 22 Jun 2016 20:26:53 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 23814 <at> debbugs.gnu.org
> 
> > From: ynyaaa <at> gmail.com
> > Cc: 23814 <at> debbugs.gnu.org
> > Date: Thu, 23 Jun 2016 02:04:18 +0900
> > 
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> > 
> > >> `encode-hz-region' uses `iso-2022-7bit' coding-system internally,
> > >> replacing it with the coding-system below will work.
> > >> 
> > >> (define-coding-system 'iso-2022-cn-gb
> > >>   "ISO 2022 based 7bit encoding only for Chinese GB2312."
> > >>   :coding-type 'iso-2022
> > >>   :mnemonic ?C
> > >>   :charset-list '(ascii chinese-gb2312)
> > >>   :designation [(ascii chinese-gb2312) nil nil nil]
> > >>   :flags '(ascii-at-eol ascii-at-cntl designation 7-bit safe)
> > >>   )
> > >
> > > What advantages does this change have?
> > 
> > `iso-2022-7bit' may encode same character to various strings,
> > while `iso-2022-cn-gb' encodes same charcter to same string.
> > 
> > (mapcar (lambda (cs) (encode-coding-string
> >                       (propertize "\x4e00" 'charset cs)
> >                       'iso-2022-7bit))
> >         '(chinese-gb2312 japanese-jisx0208 korean-ksc5601
> >                          chinese-cns11643-1))
> > =>("\e$AR;\e(B"
> >    "\e$B0l\e(B"
> >    "\e$(Cli\e(B"
> >    "\e$(GD!\e(B")
> > 
> > (mapcar (lambda (cs) (encode-coding-string
> >                       (propertize "\x4e00" 'charset cs)
> >                       'iso-2022-cn-gb))
> >         '(chinese-gb2312 japanese-jisx0208 korean-ksc5601
> >                          chinese-cns11643-1))
> > =>("\e$AR;\e(B"
> >    "\e$AR;\e(B"
> >    "\e$AR;\e(B"
> >    "\e$AR;\e(B")
> > 
> > `encode-hz-region' expects `chinese-gb2312' characters are encoded
> > with "\e$A" sequences, and replaces them to "~{".
> 
> I understand, but as I said, I think this is by design, and should not
> be changed.  However, maybe I'm missing something, so I'll CC
> Handa-san and ask him to comment on this proposal and the issue in
> general.
This bug report was last modified 8 years and 85 days ago.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.