GNU bug report logs - #8522
Arrow key trouble when keyboard encoding is euc-japan

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8522 in the body.
You can then email your comments to 8522 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: IIJIMA Hiromitsu <delmonta <at> dennougedougakkai-ndd.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Arrow key trouble when keyboard encoding is euc-japan
Date: Wed, 20 Apr 2011 00:03:45 +0900

Dear all,

I am using Emacs 23.2.1 on FreeBSD and RedHat (32-bit versions).

I have configured keyboard-encoding-system be "euc-japan" because
it is the terminal's default.

But when I upgraded Emacs to ver. 23, arrow keys began to cause
troubles when I run Emacs inside a terminal window (emacs -nw).

When I move cursor with an arrow key, the cursor movement is
reflected to the screen with one stroke delay.
C-l shows the cursor's "real" position.
It does not happen when I move cursor by C-f, C-n, etc.

HOW-TO-REPEAT: Open a file and type C-x RET k euc-japan RET.

According to the following site (in Japanese),
http://slashdot.jp/~doda/journal/516198
the cause of this trouble is that arrow keys are passed to Emacs as
ESC O {A,B,C,D} sequence and this "ESC O" is interpreted as ISO/IEC
2022's SS3 (single-shift 3) code.

This trouble occurs when the following conditions are all met:
- ISO/IEC 2022 compliant or their variants
- Using SS3
- A character set designated to G3 by default

At this moment, only Japanese EUC and its variants match the conditions.

There are some encodings that use single-shifts: iso-2022-jp-2,
iso-2022-cn, and iso-2022-cn-ext. But

  - iso-2022-jp-2 and iso-2022-cn use SS2 and do not use SS3,
  and
  - iso-2022-cn-ext uses SS3 but in this encoding G3 is empty
    at the boot time.

In addition, iso-2022-cn-ext is a 7-bit encoding and therefore you can
assume that in a 8-bit encoding, namely only Japanese EUC and its
variants, a SS3 is followed by GR byte sequence, and treat the sequence
"SS3 + GL-byte" as a void character.

The site above published the following patch.
Would you consider applying it? Thanks in advance.

--- src/coding.c.orig    2010-04-04 07:26:13.000000000 +0900
+++ src/coding.c    2010-09-24 16:42:33.000000000 +0900
@@ -3853,8 +3853,14 @@
          else
        charset = CHARSET_FROM_ID (charset_id_2);
          ONE_MORE_BYTE (c1);
-          if (c1 < 0x20 || (c1 >= 0x80 && c1 < 0xA0))
-        goto invalid_code;
+          if (CODING_ISO_FLAGS (coding) & CODING_ISO_FLAG_SEVEN_BITS) {
+        if (c1 < 0x20 || c1 >= 0x80)
+          goto invalid_code;
+          }
+          else {
+        if (c1 < 0xA0)
+          goto invalid_code;
+          }
          break;

        case 'O':        /* invocation of single-shift-3 */
@@ -3867,8 +3873,14 @@
          else
        charset = CHARSET_FROM_ID (charset_id_3);
          ONE_MORE_BYTE (c1);
-          if (c1 < 0x20 || (c1 >= 0x80 && c1 < 0xA0))
-        goto invalid_code;
+          if (CODING_ISO_FLAGS (coding) & CODING_ISO_FLAG_SEVEN_BITS) {
+        if (c1 < 0x20 || c1 >= 0x80)
+          goto invalid_code;
+          }
+          else {
+        if (c1 < 0xA0)
+          goto invalid_code;
+          }
          break;

        case '0': case '2':    case '3': case '4': /* start composition */

-- 
========================================================================
飯嶋 浩光 / でるもんた・いいじま      delmonta <at> dennougedougakkai-ndd.org
(Mr.) IIJIMA, Hiromitsu  http://www.dennougedougakkai-ndd.org/~delmonta/

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

From: Glenn Morris <rgm <at> gnu.org>
To: Kenichi Handa <handa <at> gnu.org>
Cc: 8522 <at> debbugs.gnu.org, IIJIMA Hiromitsu <delmonta <at> dennougedougakkai-ndd.org>
Subject: Re: bug#8522: Arrow key trouble when keyboard encoding is euc-japan
Date: Tue, 16 Jul 2013 15:08:31 -0400

Please could you take a look at this report?
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8522

IIJIMA Hiromitsu wrote:

> I am using Emacs 23.2.1 on FreeBSD and RedHat (32-bit versions).
>
> I have configured keyboard-encoding-system be "euc-japan" because
> it is the terminal's default.
>
> But when I upgraded Emacs to ver. 23, arrow keys began to cause
> troubles when I run Emacs inside a terminal window (emacs -nw).
>
> When I move cursor with an arrow key, the cursor movement is
> reflected to the screen with one stroke delay.
> C-l shows the cursor's "real" position.
> It does not happen when I move cursor by C-f, C-n, etc.
>
> HOW-TO-REPEAT: Open a file and type C-x RET k euc-japan RET.
>
> According to the following site (in Japanese),
> http://slashdot.jp/~doda/journal/516198
> the cause of this trouble is that arrow keys are passed to Emacs as
> ESC O {A,B,C,D} sequence and this "ESC O" is interpreted as ISO/IEC
> 2022's SS3 (single-shift 3) code.
>
> This trouble occurs when the following conditions are all met:
> - ISO/IEC 2022 compliant or their variants
> - Using SS3
> - A character set designated to G3 by default
>
> At this moment, only Japanese EUC and its variants match the conditions.
>
> There are some encodings that use single-shifts: iso-2022-jp-2,
> iso-2022-cn, and iso-2022-cn-ext. But
>
>   - iso-2022-jp-2 and iso-2022-cn use SS2 and do not use SS3,
>   and
>   - iso-2022-cn-ext uses SS3 but in this encoding G3 is empty
>     at the boot time.
>
> In addition, iso-2022-cn-ext is a 7-bit encoding and therefore you can
> assume that in a 8-bit encoding, namely only Japanese EUC and its
> variants, a SS3 is followed by GR byte sequence, and treat the sequence
> "SS3 + GL-byte" as a void character.
>
> The site above published the following patch.
> Would you consider applying it? Thanks in advance.
>
> --- src/coding.c.orig    2010-04-04 07:26:13.000000000 +0900
> +++ src/coding.c    2010-09-24 16:42:33.000000000 +0900
> @@ -3853,8 +3853,14 @@
>           else
>         charset = CHARSET_FROM_ID (charset_id_2);
>           ONE_MORE_BYTE (c1);
> -          if (c1 < 0x20 || (c1 >= 0x80 && c1 < 0xA0))
> -        goto invalid_code;
> +          if (CODING_ISO_FLAGS (coding) & CODING_ISO_FLAG_SEVEN_BITS) {
> +        if (c1 < 0x20 || c1 >= 0x80)
> +          goto invalid_code;
> +          }
> +          else {
> +        if (c1 < 0xA0)
> +          goto invalid_code;
> +          }
>           break;
>
>         case 'O':        /* invocation of single-shift-3 */
> @@ -3867,8 +3873,14 @@
>           else
>         charset = CHARSET_FROM_ID (charset_id_3);
>           ONE_MORE_BYTE (c1);
> -          if (c1 < 0x20 || (c1 >= 0x80 && c1 < 0xA0))
> -        goto invalid_code;
> +          if (CODING_ISO_FLAGS (coding) & CODING_ISO_FLAG_SEVEN_BITS) {
> +        if (c1 < 0x20 || c1 >= 0x80)
> +          goto invalid_code;
> +          }
> +          else {
> +        if (c1 < 0xA0)
> +          goto invalid_code;
> +          }
>           break;
>
>         case '0': case '2':    case '3': case '4': /* start composition */

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

From: Handa Kenichi <handa <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 8522 <at> debbugs.gnu.org, delmonta <at> dennougedougakkai-ndd.org
Subject: Re: bug#8522: Arrow key trouble when keyboard encoding is euc-japan
Date: Thu, 18 Jul 2013 07:18:55 -0400

In article <70ppui8gr4.fsf <at> fencepost.gnu.org>, Glenn Morris
<rgm <at> gnu.org> writes:

> Please could you take a look at this report?
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8522

Ok.  Please wait for a while.

---
Kenichi Handa
handa <at> gnu.org

> IIJIMA Hiromitsu wrote:

> > I am using Emacs 23.2.1 on FreeBSD and RedHat (32-bit versions).
> >
> > I have configured keyboard-encoding-system be "euc-japan" because
> > it is the terminal's default.
> >
> > But when I upgraded Emacs to ver. 23, arrow keys began to cause
> > troubles when I run Emacs inside a terminal window (emacs -nw).
> >
> > When I move cursor with an arrow key, the cursor movement is
> > reflected to the screen with one stroke delay.
> > C-l shows the cursor's "real" position.
> > It does not happen when I move cursor by C-f, C-n, etc.
> >
> > HOW-TO-REPEAT: Open a file and type C-x RET k euc-japan RET.
> >
> > According to the following site (in Japanese),
> > http://slashdot.jp/~doda/journal/516198
> > the cause of this trouble is that arrow keys are passed to Emacs as
> > ESC O {A,B,C,D} sequence and this "ESC O" is interpreted as ISO/IEC
> > 2022's SS3 (single-shift 3) code.
> >
> > This trouble occurs when the following conditions are all met:
> > - ISO/IEC 2022 compliant or their variants
> > - Using SS3
> > - A character set designated to G3 by default
> >
> > At this moment, only Japanese EUC and its variants match the
> > conditions.
> >
> > There are some encodings that use single-shifts: iso-2022-jp-2,
> > iso-2022-cn, and iso-2022-cn-ext. But
> >
> >   - iso-2022-jp-2 and iso-2022-cn use SS2 and do not use SS3,
> >   and
> >   - iso-2022-cn-ext uses SS3 but in this encoding G3 is empty
> >     at the boot time.
> >
> > In addition, iso-2022-cn-ext is a 7-bit encoding and therefore you
> > can
> > assume that in a 8-bit encoding, namely only Japanese EUC and its
> > variants, a SS3 is followed by GR byte sequence, and treat the
> > sequence
> > "SS3 + GL-byte" as a void character.
> >
> > The site above published the following patch.
> > Would you consider applying it? Thanks in advance.
> >
> > --- src/coding.c.orig    2010-04-04 07:26:13.000000000 +0900
> > +++ src/coding.c    2010-09-24 16:42:33.000000000 +0900
> > @@ -3853,8 +3853,14 @@
> >           else
> >         charset = CHARSET_FROM_ID (charset_id_2);
> >           ONE_MORE_BYTE (c1);
> > -          if (c1 < 0x20 || (c1 >= 0x80 && c1 < 0xA0))
> > -        goto invalid_code;
> > +          if (CODING_ISO_FLAGS (coding) &
> > CODING_ISO_FLAG_SEVEN_BITS) {
> > +        if (c1 < 0x20 || c1 >= 0x80)
> > +          goto invalid_code;
> > +          }
> > +          else {
> > +        if (c1 < 0xA0)
> > +          goto invalid_code;
> > +          }
> >           break;
> >
> >         case 'O':        /* invocation of single-shift-3 */
> > @@ -3867,8 +3873,14 @@
> >           else
> >         charset = CHARSET_FROM_ID (charset_id_3);
> >           ONE_MORE_BYTE (c1);
> > -          if (c1 < 0x20 || (c1 >= 0x80 && c1 < 0xA0))
> > -        goto invalid_code;
> > +          if (CODING_ISO_FLAGS (coding) &
> > CODING_ISO_FLAG_SEVEN_BITS) {
> > +        if (c1 < 0x20 || c1 >= 0x80)
> > +          goto invalid_code;
> > +          }
> > +          else {
> > +        if (c1 < 0xA0)
> > +          goto invalid_code;
> > +          }
> >           break;
> >
> >         case '0': case '2':    case '3': case '4': /* start
> >         composition */

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

From: Hiroki Sato <hrs <at> FreeBSD.org>
To: 8522 <at> debbugs.gnu.org
Cc: rgm <at> gnu.org, ashish <at> FreeBSD.org, hrs <at> FreeBSD.org,
 delmonta <at> dennougedougakkai-ndd.org
Subject: Re: bug#8522: Arrow key trouble when keyboard encoding is euc-japan
Date: Fri, 19 Jul 2013 12:02:35 +0900 (JST)

[Message part 1 (text/plain, inline)]

Hi,

 I could reproduce the problem in #8522 and am using Emacs 24.3 with
 the patch in [*] (basically the same as one submitted in #8522) on
 FreeBSD.  It is working fine with no side effect.

 [*] http://svnweb.freebsd.org/ports/head/editors/emacs/files/patch-src_coding.c?view=markup&pathrev=281397

-- Hiroki

[Message part 2 (application/pgp-signature, inline)]

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

From: Handa Kenichi <handa <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 8522 <at> debbugs.gnu.org, delmonta <at> dennougedougakkai-ndd.org
Subject: Re: bug#8522: Arrow key trouble when keyboard encoding is euc-japan
Date: Sat, 20 Jul 2013 08:29:39 -0400

In article <70ppui8gr4.fsf <at> fencepost.gnu.org>, Glenn Morris <rgm <at> gnu.org> writes:

> Please could you take a look at this report?
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8522

I've just installed a little bit different fix.

> IIJIMA Hiromitsu wrote:
[...]
> > According to the following site (in Japanese),
> > http://slashdot.jp/~doda/journal/516198
> > the cause of this trouble is that arrow keys are passed to Emacs as
> > ESC O {A,B,C,D} sequence and this "ESC O" is interpreted as ISO/IEC
> > 2022's SS3 (single-shift 3) code.
> >
> > This trouble occurs when the following conditions are all met:
> > - ISO/IEC 2022 compliant or their variants
> > - Using SS3
> > - A character set designated to G3 by default
> >
> > At this moment, only Japanese EUC and its variants match the
> > conditions.
> >
> > There are some encodings that use single-shifts: iso-2022-jp-2,
> > iso-2022-cn, and iso-2022-cn-ext. But
> >
> >   - iso-2022-jp-2 and iso-2022-cn use SS2 and do not use SS3,
> >   and
> >   - iso-2022-cn-ext uses SS3 but in this encoding G3 is empty
> >     at the boot time.
> >
> > In addition, iso-2022-cn-ext is a 7-bit encoding and therefore you
> > can
> > assume that in a 8-bit encoding, namely only Japanese EUC and its
> > variants, a SS3 is followed by GR byte sequence, and treat the
> > sequence
> > "SS3 + GL-byte" as a void character.

That analysis is correct.  But, as ISO 2022 has a concept of
"implementation level" which specifies which graphic plane
(GL or GR) is indentified as the single-shift area, I
introduced a new flag `8-bit-level-4' for ISO-2022 base
coding system.  By default, that flag is not set, thus the
implementation level of the 2022 decoder is "4A" which means
GR is identified as the single-shift area.  So, the cursor
key sequences ESC O A, etc are not recognized as a valid
single-shift sequence, and thus those sequences are given to
the normal key-sequence look-up mechanism.

---
Kenichi Handa
handa <at> gnu.org

Previous Next

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