From: Handa Kenichi <handa@gnu.org>
To: Glenn Morris <rgm@gnu.org>
Cc: 8522@debbugs.gnu.org, delmonta@dennougedougakkai-ndd.org
Subject: bug#8522: Arrow key trouble when keyboard encoding is euc-japan
Date: Thu, 18 Jul 2013 07:18:55 -0400 [thread overview]
Message-ID: <yw7k3koqfog.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <70ppui8gr4.fsf@fencepost.gnu.org> (message from Glenn Morris on Tue, 16 Jul 2013 15:08:31 -0400)
In article <70ppui8gr4.fsf@fencepost.gnu.org>, Glenn Morris
<rgm@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@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 */
next prev parent reply other threads:[~2013-07-18 11:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-19 15:03 bug#8522: Arrow key trouble when keyboard encoding is euc-japan IIJIMA Hiromitsu
2013-07-16 19:08 ` Glenn Morris
2013-07-18 11:18 ` Handa Kenichi [this message]
2013-07-20 12:29 ` Handa Kenichi
2013-07-19 3:02 ` Hiroki Sato
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=yw7k3koqfog.fsf@fencepost.gnu.org \
--to=handa@gnu.org \
--cc=8522@debbugs.gnu.org \
--cc=delmonta@dennougedougakkai-ndd.org \
--cc=rgm@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).