GNU bug report logs - #16645
24.3; in xterm, keypad = is translated to M-o x

Previous Next

Package: emacs;

Reported by: Vincent Lefevre <vincent <at> vinc17.net>

Date: Tue, 4 Feb 2014 23:59:01 UTC

Severity: normal

Tags: moreinfo

Found in version 24.3

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#16645; Package emacs. (Tue, 04 Feb 2014 23:59:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Vincent Lefevre <vincent <at> vinc17.net>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Tue, 04 Feb 2014 23:59:02 GMT) Full text and rfc822 format available.

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

From: Vincent Lefevre <vincent <at> vinc17.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3; in xterm, keypad = is translated to M-o x
Date: Wed, 05 Feb 2014 00:58:14 +0100
With "emacs -Q -nw" in xterm, the keypad = key (keysym 0xffbd, KP_Equal)
is translated to M-o x instead of the = character.


In GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.8.6)
 of 2013-12-22 on brahms, modified by Debian
System Description:	Debian GNU/Linux unstable (sid)

Configured using:
 `configure '--build' 'x86_64-linux-gnu' '--build' 'x86_64-linux-gnu'
 '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib'
 '--localstatedir=/var/lib' '--infodir=/usr/share/info'
 '--mandir=/usr/share/man' '--with-pop=yes'
 '--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.3/site-lisp:/usr/share/emacs/site-lisp'
 '--with-crt-dir=/usr/lib/x86_64-linux-gnu' '--with-x=yes'
 '--with-x-toolkit=gtk3' '--with-toolkit-scroll-bars'
 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector
 --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall'
 'LDFLAGS=-Wl,-z,relro' 'CPPFLAGS=-D_FORTIFY_SOURCE=2''

Important settings:
  value of $LC_COLLATE: POSIX
  value of $LC_CTYPE: en_US.UTF-8
  value of $LC_TIME: en_DK
  value of $LANG: POSIX
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  display-time-mode: t
  show-paren-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
ESC [ > 4 1 ; 3 0 1 ; 0 c ESC ] 1 1 ; r g b : 0 0 0 
0 / 0 0 0 0 / 0 0 0 0 ESC \ C-s ESC O X ESC x r e p 
o r t - e m TAB RET

Recent messages:
Loading /etc/emacs/site-start.d/50latex-cjk-common.el (source)...
Loading cjk-enc...done
Loading /etc/emacs/site-start.d/50latex-cjk-common.el (source)...done
Loading /etc/emacs/site-start.d/50latex-cjk-thai.el (source)...done
Loading /etc/emacs/site-start.d/50psvn.el (source)...done
Loading /etc/emacs/site-start.d/50rnc-mode.el (source)...done
Loading /etc/emacs/site-start.d/50w3m-el.el (source)...done
Loading /home/vinc17/share/emacs/site-lisp/mutteditor.el (source)...done
Loading time...done
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
/usr/share/emacs24/site-lisp/css-mode/css-mode hides /usr/share/emacs/site-lisp/css-mode/css-mode
/usr/share/emacs/24.3/site-lisp/debian-startup hides /usr/share/emacs/site-lisp/debian-startup
/usr/share/emacs/site-lisp/autoconf/autotest-mode hides /usr/share/emacs/site-lisp/autotest-mode
/usr/share/emacs24/site-lisp/html-helper-mode/tempo hides /usr/share/emacs/24.3/lisp/tempo
/usr/share/emacs24/site-lisp/flim/hex-util hides /usr/share/emacs/24.3/lisp/hex-util
/usr/share/emacs24/site-lisp/flim/md4 hides /usr/share/emacs/24.3/lisp/md4
/usr/share/emacs24/site-lisp/dictionaries-common/flyspell hides /usr/share/emacs/24.3/lisp/textmodes/flyspell
/usr/share/emacs24/site-lisp/dictionaries-common/ispell hides /usr/share/emacs/24.3/lisp/textmodes/ispell
/usr/share/emacs24/site-lisp/css-mode/css-mode hides /usr/share/emacs/24.3/lisp/textmodes/css-mode
/usr/share/emacs24/site-lisp/flim/hmac-md5 hides /usr/share/emacs/24.3/lisp/net/hmac-md5
/usr/share/emacs24/site-lisp/flim/sasl-ntlm hides /usr/share/emacs/24.3/lisp/net/sasl-ntlm
/usr/share/emacs24/site-lisp/flim/sasl-cram hides /usr/share/emacs/24.3/lisp/net/sasl-cram
/usr/share/emacs24/site-lisp/flim/ntlm hides /usr/share/emacs/24.3/lisp/net/ntlm
/usr/share/emacs24/site-lisp/flim/sasl hides /usr/share/emacs/24.3/lisp/net/sasl
/usr/share/emacs24/site-lisp/flim/hmac-def hides /usr/share/emacs/24.3/lisp/net/hmac-def
/usr/share/emacs24/site-lisp/flim/sasl-digest hides /usr/share/emacs/24.3/lisp/net/sasl-digest
/usr/share/emacs24/site-lisp/latex-cjk-thai/thai-word hides /usr/share/emacs/24.3/lisp/language/thai-word
/usr/share/emacs24/site-lisp/html-helper-mode/html-helper-mode hides /usr/share/emacs/site-lisp/html-helper-mode/html-helper-mode
/usr/share/emacs24/site-lisp/html-helper-mode/hhm-config hides /usr/share/emacs/site-lisp/html-helper-mode/hhm-config
/usr/share/emacs24/site-lisp/html-helper-mode/tempo hides /usr/share/emacs/site-lisp/html-helper-mode/tempo
/usr/share/emacs24/site-lisp/html-helper-mode/visual-basic-mode hides /usr/share/emacs/site-lisp/html-helper-mode/visual-basic-mode

Features:
(shadow sort gnus-util mail-extr warnings emacsbug message format-spec
rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils misearch multi-isearch time
cus-start cus-load time-date paren cc-styles cc-align cc-engine cc-vars
cc-defs w3m-load jabber-autoloads tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
make-network-process dbusbind dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16645; Package emacs. (Wed, 05 Feb 2014 00:17:01 GMT) Full text and rfc822 format available.

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

From: Vincent Lefevre <vincent <at> vinc17.net>
To: 16645 <at> debbugs.gnu.org
Subject: Re: 24.3; in xterm, keypad = is translated to M-o x
Date: Wed, 5 Feb 2014 01:15:48 +0100
On 2014-02-05 00:58:14 +0100, Vincent Lefevre wrote:
> With "emacs -Q -nw" in xterm, the keypad = key (keysym 0xffbd, KP_Equal)
> is translated to M-o x instead of the = character.

According to "tack", the keypad "=" gives:

^[OX       Unknown

instead of

=          Unknown

Then, I don't know yet whether this is intentional or this is a bug
in xterm. And why the different case for "o" and "x" (uppercase in
tack, lowercase in Emacs)?

In any case, I can see nothing about kp-equal in the xterm.el file.
About the keypad, just:

    (define-key map "\eOj" [kp-multiply])
    (define-key map "\eOk" [kp-add])
    (define-key map "\eOl" [kp-separator])
    (define-key map "\eOm" [kp-subtract])
    (define-key map "\eOo" [kp-divide])
    (define-key map "\eOp" [kp-0])
    (define-key map "\eOq" [kp-1])
    (define-key map "\eOr" [kp-2])
    (define-key map "\eOs" [kp-3])
    (define-key map "\eOt" [kp-4])
    (define-key map "\eOu" [kp-5])
    (define-key map "\eOv" [kp-6])
    (define-key map "\eOw" [kp-7])
    (define-key map "\eOx" [kp-8])
    (define-key map "\eOy" [kp-9])

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16645; Package emacs. (Wed, 05 Feb 2014 01:18:01 GMT) Full text and rfc822 format available.

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

From: Vincent Lefevre <vincent <at> vinc17.net>
To: 16645 <at> debbugs.gnu.org
Subject: Re: 24.3; in xterm, keypad = is translated to M-o x
Date: Wed, 5 Feb 2014 02:17:01 +0100
On 2014-02-05 01:15:48 +0100, Vincent Lefevre wrote:
> On 2014-02-05 00:58:14 +0100, Vincent Lefevre wrote:
> > With "emacs -Q -nw" in xterm, the keypad = key (keysym 0xffbd, KP_Equal)
> > is translated to M-o x instead of the = character.
> 
> According to "tack", the keypad "=" gives:
> 
> ^[OX       Unknown
> 
> instead of
> 
> =          Unknown
> 
> Then, I don't know yet whether this is intentional or this is a bug
> in xterm.

It was due to my XKB settings (only the "=" keypad key gave a
KP_something keysym due to missing configuration for this key,
contrary to the other keypad ones). So, now that the "=" keypad
key gives a normal "=" keysym, the problem is no longer visible
in Emacs on my machine. However I'm still wondering about the
remarks below:

> And why the different case for "o" and "x" (uppercase in
> tack, lowercase in Emacs)?
> 
> In any case, I can see nothing about kp-equal in the xterm.el file.
> About the keypad, just:
> 
>     (define-key map "\eOj" [kp-multiply])
>     (define-key map "\eOk" [kp-add])
>     (define-key map "\eOl" [kp-separator])
>     (define-key map "\eOm" [kp-subtract])
>     (define-key map "\eOo" [kp-divide])
>     (define-key map "\eOp" [kp-0])
>     (define-key map "\eOq" [kp-1])
>     (define-key map "\eOr" [kp-2])
>     (define-key map "\eOs" [kp-3])
>     (define-key map "\eOt" [kp-4])
>     (define-key map "\eOu" [kp-5])
>     (define-key map "\eOv" [kp-6])
>     (define-key map "\eOw" [kp-7])
>     (define-key map "\eOx" [kp-8])
>     (define-key map "\eOy" [kp-9])

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16645; Package emacs. (Sat, 28 Mar 2020 00:56:01 GMT) Full text and rfc822 format available.

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Vincent Lefevre <vincent <at> vinc17.net>
Cc: 16645 <at> debbugs.gnu.org
Subject: Re: bug#16645: 24.3; in xterm, keypad = is translated to M-o x
Date: Sat, 28 Mar 2020 01:55:40 +0100
Vincent Lefevre <vincent <at> vinc17.net> writes:

> On 2014-02-05 01:15:48 +0100, Vincent Lefevre wrote:
>> On 2014-02-05 00:58:14 +0100, Vincent Lefevre wrote:
>> > With "emacs -Q -nw" in xterm, the keypad = key (keysym 0xffbd, KP_Equal)
>> > is translated to M-o x instead of the = character.
>> 
>> According to "tack", the keypad "=" gives:
>> 
>> ^[OX       Unknown
>> 
>> instead of
>> 
>> =          Unknown
>> 
>> Then, I don't know yet whether this is intentional or this is a bug
>> in xterm.
>
> It was due to my XKB settings (only the "=" keypad key gave a
> KP_something keysym due to missing configuration for this key,
> contrary to the other keypad ones).

So it seems like this was not a bug in Emacs?  Could this bug
therefore be closed?

>                                     So, now that the "=" keypad
> key gives a normal "=" keysym, the problem is no longer visible
> in Emacs on my machine. However I'm still wondering about the
> remarks below:

I'm assuming you are here referring the difference between "^[OX" and
"\eOx"?  It seems to me that it's just a difference in how this keysym
is displayed by Emacs and tack.

>> And why the different case for "o" and "x" (uppercase in
>> tack, lowercase in Emacs)?
>> 
>> In any case, I can see nothing about kp-equal in the xterm.el file.
>> About the keypad, just:
>> 
>>     (define-key map "\eOj" [kp-multiply])
>>     (define-key map "\eOk" [kp-add])
>>     (define-key map "\eOl" [kp-separator])
>>     (define-key map "\eOm" [kp-subtract])
>>     (define-key map "\eOo" [kp-divide])
>>     (define-key map "\eOp" [kp-0])
>>     (define-key map "\eOq" [kp-1])
>>     (define-key map "\eOr" [kp-2])
>>     (define-key map "\eOs" [kp-3])
>>     (define-key map "\eOt" [kp-4])
>>     (define-key map "\eOu" [kp-5])
>>     (define-key map "\eOv" [kp-6])
>>     (define-key map "\eOw" [kp-7])
>>     (define-key map "\eOx" [kp-8])
>>     (define-key map "\eOy" [kp-9])

Best regards,
Stefan Kangas




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16645; Package emacs. (Sat, 28 Mar 2020 01:24:02 GMT) Full text and rfc822 format available.

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

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 16645 <at> debbugs.gnu.org
Subject: Re: bug#16645: 24.3; in xterm, keypad = is translated to M-o x
Date: Sat, 28 Mar 2020 02:23:27 +0100
On 2020-03-28 01:55:40 +0100, Stefan Kangas wrote:
> Vincent Lefevre <vincent <at> vinc17.net> writes:
> 
> > On 2014-02-05 01:15:48 +0100, Vincent Lefevre wrote:
> >> On 2014-02-05 00:58:14 +0100, Vincent Lefevre wrote:
> >> > With "emacs -Q -nw" in xterm, the keypad = key (keysym 0xffbd, KP_Equal)
> >> > is translated to M-o x instead of the = character.
> >> 
> >> According to "tack", the keypad "=" gives:
> >> 
> >> ^[OX       Unknown
> >> 
> >> instead of
> >> 
> >> =          Unknown
> >> 
> >> Then, I don't know yet whether this is intentional or this is a bug
> >> in xterm.
> >
> > It was due to my XKB settings (only the "=" keypad key gave a
> > KP_something keysym due to missing configuration for this key,
> > contrary to the other keypad ones).
> 
> So it seems like this was not a bug in Emacs?

I think that there's something missing for Emacs. As I've said, the
xterm.el file contains only:

    (define-key map "\eOj" [kp-multiply])
    (define-key map "\eOk" [kp-add])
    (define-key map "\eOl" [kp-separator])
    (define-key map "\eOm" [kp-subtract])
    (define-key map "\eOo" [kp-divide])
    (define-key map "\eOp" [kp-0])
    (define-key map "\eOq" [kp-1])
    (define-key map "\eOr" [kp-2])
    (define-key map "\eOs" [kp-3])
    (define-key map "\eOt" [kp-4])
    (define-key map "\eOu" [kp-5])
    (define-key map "\eOv" [kp-6])
    (define-key map "\eOw" [kp-7])
    (define-key map "\eOx" [kp-8])
    (define-key map "\eOy" [kp-9])

Why nothing for [kp-equal]?

> >                                     So, now that the "=" keypad
> > key gives a normal "=" keysym, the problem is no longer visible
> > in Emacs on my machine. However I'm still wondering about the
> > remarks below:
> 
> I'm assuming you are here referring the difference between "^[OX" and
> "\eOx"?  It seems to me that it's just a difference in how this keysym
> is displayed by Emacs and tack.

But my point is that the case for "O" and "X" matters. For instance,
M-O A moves the cursor up, but M-O a is undefined.

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16645; Package emacs. (Mon, 06 Sep 2021 09:37:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Vincent Lefevre <vincent <at> vinc17.net>
Cc: Stefan Kangas <stefan <at> marxist.se>, 16645 <at> debbugs.gnu.org
Subject: Re: bug#16645: 24.3; in xterm, keypad = is translated to M-o x
Date: Mon, 06 Sep 2021 11:36:10 +0200
Vincent Lefevre <vincent <at> vinc17.net> writes:

>     (define-key map "\eOx" [kp-8])
>     (define-key map "\eOy" [kp-9])
>
> Why nothing for [kp-equal]?

Yes, that seems odd.

Just to check -- does tack say that 9 on the keypad gives Ox and = on
the keypad gives OX?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Added tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 06 Sep 2021 09:37:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16645; Package emacs. (Mon, 06 Sep 2021 10:00:02 GMT) Full text and rfc822 format available.

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Vincent Lefevre <vincent <at> vinc17.net>
Cc: Stefan Kangas <stefan <at> marxist.se>, 16645 <at> debbugs.gnu.org
Subject: Re: bug#16645: 24.3; in xterm, keypad = is translated to M-o x
Date: Mon, 06 Sep 2021 11:59:55 +0200
On Mär 28 2020, Vincent Lefevre wrote:

> Why nothing for [kp-equal]?

Probably because PC keyboards don't come with a '=' key on the keypad.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16645; Package emacs. (Tue, 07 Sep 2021 09:54:02 GMT) Full text and rfc822 format available.

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

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Andreas Schwab <schwab <at> linux-m68k.org>
Cc: Stefan Kangas <stefan <at> marxist.se>, 16645 <at> debbugs.gnu.org
Subject: Re: bug#16645: 24.3; in xterm, keypad = is translated to M-o x
Date: Tue, 7 Sep 2021 11:53:52 +0200
On 2021-09-06 11:36:10 +0200, Lars Ingebrigtsen wrote:
> Vincent Lefevre <vincent <at> vinc17.net> writes:
> 
> >     (define-key map "\eOx" [kp-8])
> >     (define-key map "\eOy" [kp-9])
> >
> > Why nothing for [kp-equal]?
> 
> Yes, that seems odd.
> 
> Just to check -- does tack say that 9 on the keypad gives Ox and = on
> the keypad gives OX?

In xterm, tack says for the keypad keys 8, 9 and =:

^[Ox       (ka2)
^[Oy       (ka3)
^[OX       Unknown

So the meaning of ^[OX is unknown for tack and also ncurses.

I wonder whether this sequence is generated by xterm or some library.

On 2021-09-06 11:59:55 +0200, Andreas Schwab wrote:
> On Mär 28 2020, Vincent Lefevre wrote:
> 
> > Why nothing for [kp-equal]?
> 
> Probably because PC keyboards don't come with a '=' key on the keypad.

Indeed. The keypad of the PC keyboards seems to come from the
VT220 keypad block: ncurses has a file misc/terminfo.src with

# With the VT220 keypad block that uses the 1-9 keys as suggested in
# terminfo(5), the other keys can be handled with user-defined capabilities:
#
#   _______________________________________
#  | NumLock |    /    |    *    |    -    |
#  |         |   $Oo   |   $Oj   |   $OS   |
#  |_________|__kpDIV__|__kpMUL__|__kpSUB__|
#  |    7         8         9    |         |
#  |   $Ow   |   $Ox   |   $Oy   |    +    |
#  |_ka1__K1_|_________|_ka3__K3_|   $Ok   |
#  |    4    |    5    |    6    |  kpADD  |
#  |   $Ot   |   $Ou   |   $Ov   |         |
#  |_________|_kb2__K2_|_________|_________|
#  |    1    |    2    |    3    |         |
#  |   $Oq   |   $Or   |   $Os   |         |
#  |_kc1__K4_|_________|_kc3__K5_|  enter  |
#  |         0         |   .     |   $OM   |
#  |        $Op        |  $On    |         |
#  |___________________|_________|_kent_ <at> 8_|
#
xterm+keypad|xterm emulating VT100/VT220 numeric keypad,
        kp5=\EOE, kpADD=\EOk, kpCMA=\EOl, kpDIV=\EOo, kpDOT=\EOn,
        kpMUL=\EOj, kpSUB=\EOm, kpZRO=\EOp, use=vt220+keypad,

The keypad "=" key is an additional key on my Apple keyboard
(where the "+" key has a normal size instead of a double size,
allowing this additional key).

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16645; Package emacs. (Wed, 08 Sep 2021 07:26:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Vincent Lefevre <vincent <at> vinc17.net>
Cc: Stefan Kangas <stefan <at> marxist.se>, Andreas Schwab <schwab <at> linux-m68k.org>,
 16645 <at> debbugs.gnu.org
Subject: Re: bug#16645: 24.3; in xterm, keypad = is translated to M-o x
Date: Wed, 08 Sep 2021 09:25:26 +0200
Vincent Lefevre <vincent <at> vinc17.net> writes:

> In xterm, tack says for the keypad keys 8, 9 and =:
>
> ^[Ox       (ka2)
> ^[Oy       (ka3)
> ^[OX       Unknown
>
> So the meaning of ^[OX is unknown for tack and also ncurses.

Thanks.

> The keypad "=" key is an additional key on my Apple keyboard
> (where the "+" key has a normal size instead of a double size,
> allowing this additional key).

Right.  Adding this mapping shouldn't regress anything, and it should
fix this issue, so I've now added the mapping to xterm.el in Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug marked as fixed in version 28.1, send any further explanations to 16645 <at> debbugs.gnu.org and Vincent Lefevre <vincent <at> vinc17.net> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Wed, 08 Sep 2021 07:26:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 06 Oct 2021 11:24:08 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 336 days ago.

Previous Next


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