This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: emacs -nw keypad

On 5/26/2009 9:11 PM, Tim Adye wrote:
In Cygwin 1.5 xterm (TERM=xterm), with "emacs -q -nw" (or also with "-f
tpu-edt") I get

ESC [ > 1 ; 2 4 2 ; 0 c ESC O q ESC O r ESC O s ESC
O t ESC O u ESC O v ESC O P l

The initial "ESC [ > 1 ; 2 4 2 ; 0 c" is just the response from xterm, asked
for its version number (242). The "ESC O q" to "ESC O v" are the keypad
"123456", but somehow with numlock on (perhaps this is a feature of my
Exceed X-server). The "ESC O P l" is the "F1 l" at the end.

Despite the differences, it looks like neither of us is getting any
interpretation of the keys.

As I understand the emacs documentation, the setting TERM=xterm should cause emacs to load term/xterm.el. In that file I find lines like

(define-key map "\eOq" [kp-1])
(define-key map "\eOr" [kp-2])

This looks like the place where emacs should learn to interpret the keypad keys. So is this library failing to load for some reason? Is there some initialization that emacs does (perhaps using the ncurses library) that overrides the setting of TERM? I mentioned ncurses because that's something else that has been updated recently in the cygwin distribution.


P.S. I said in an earlier email that, after starting emacs, TERM has the value "dumb". This turns out to be irrelevant. Emacs apparently does this for the benefit of subprocesses that it might start.

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]