bug#23814: 24.5; bug of hz coding-system

[Eli Zaretskii <eliz@gnu.org>]

> From: ynyaaa@gmail.com
> Cc: 23814@debbugs.gnu.org
> Date: Thu, 23 Jun 2016 02:04:18 +0900
> 
> Eli Zaretskii <eliz@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.