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 #20 received at 23814 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: ynyaaa <at> gmail.com, Kenichi Handa <handa <at> gnu.org>
Cc: 23814 <at> debbugs.gnu.org
Subject: Re: bug#23814: 24.5; bug of hz coding-system
Date: Wed, 22 Jun 2016 20:26:53 +0300

> 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.