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

Previous Next

Full log

View this message in rfc822 format

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