On Wed, Feb 03, 1999 at 10:27:15PM -0600, Chris Csanady wrote: > >>On Wed, Feb 03, 1999 at 09:53:05PM -0600, Chris Csanady wrote: >>>I unfortunately have a lot of data to type in, and to my surprise >>>the keypad is unuseable in vi. It doesn't even work in vim. Thank >>>god it works on Irix--I thought I would be using ee. >>> >>>Anyways, here is what happens when I type the digits 1-9 on the >>>keypad while in insert mode.. >>> >>>y >>>x >>>w >>>v >>>u >>>t >>>s >>>r >>>q >> >>You don't say what terminal emulator you're using, but with xterm, the >>"application keypad" option gets enabled when entering vi, which prevents >>the keypad from generating numbers. You can change it once in vi with >>the <Ctrl>+left-button menu. I haven't looked into this sufficiently >>to know the direct cause of this behaviour. Maybe it could be avoided >>by tuning the termcap entry? Maybe 'vi' (as the application) should >>interpret the sequences in the correct way? > >This was using the xterm termcap entry. Although when I login to other >machines running DU4.0 or Irix6, vi works without touching anything. >Regardless, I would be inclined to blame this on our vi. I don't >understand much about tercap entries, but this certainly violates POLA. :( > >So does this mean that the default xterm entry should be different?
OK, I've looked into it a little now. It is the ks sequence, which is defined to set the cursor keys and the keypad to "application" mode in both the FreeBSD (3.0-stable as of a week ago) and XFree86 3.3.3.1 versions of the xterm termcap entries. In the FreeBSD case, it ends up falling back to the vt100 entry for this. Here are the definitions: ks=\E[?1h\E=:ke=\E[?1l\E>: \E[?1h sets the cursor keys to application mode \E= sets the keypad to application mode Maybe xterm could use a "keksInhibit" resource like the titeInhibit resource? David To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
