Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!bloom-beacon!EXPO.LCS.MIT.EDU!gildea
From: gildea@EXPO.LCS.MIT.EDU (Stephen Gildea)
Newsgroups: comp.windows.x
Subject: Re: Xterm translations in vi/nn
Message-ID: <9012202306.AA16572@excalibur.lcs.mit.edu>
Date: 20 Dec 90 23:06:53 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 32


    Date: 20 Dec 90 12:42:12 GMT
    From: garyb@abekrd.co.uk (Gary Bartlett)
    
    My normal windows are xterms. I have a numeric keypad which
    normally produces the correct characters - for instance pressing
    'KP_0' generates a '0'. But when I start up vi (and nn) in this
    xterm window, the KP_0 generates the corresponding vt100 escape
    code (I think) (eg - KP_0 -> ^[Op).  Can someone explain this
    please.  Does xterm map the key differently for raw mode
    operation?

The explanation is that xterm is correctly emulating a VT100.  The
VT100 keypad has several modes, which are controlled by ESC sequences.
When vi (or any curses-based application) starts up, it reads the
termcap/terminfo for the terminal and sends sequences defined there
for "begin keypad application."  This typically shifts the terminal
into a mode where the keypad keys generate escape sequences.  This
behavior is desirable because complex screen-based programs may want
to be able to distinguish between the main keyboard '0' key and the
keypad '0'.  EDT comes to mind here.  I've made use of this feature in
Emacs, too.
    
    How can I get KP_0 to generate a 0 in vi (other than with a map!
    in my .exrc).

Actually, a map command is not such a bad idea.  Your other options
are to create and/or install a termcap or terminfo entry more to your
liking, or define XTerm*VT100 translations for the keypad keys.

 < Stephen
   gildea@expo.lcs.mit.edu