From owner-freebsd-bugs Sat May 20 12:23:37 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA06590 for bugs-outgoing; Sat, 20 May 1995 12:23:37 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA06584 ; Sat, 20 May 1995 12:23:36 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA06222; Sat, 20 May 95 13:15:55 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9505201915.AA06222@cs.weber.edu> Subject: Re: Changed information for PR misc/409 To: nox@jelal.hb.north.de (Juergen Lock) Date: Sat, 20 May 95 13:15:54 MDT Cc: ache@freefall.cdrom.com, freebsd-bugs@freefall.cdrom.com In-Reply-To: <9505200031.AA00464@jelal.hb.north.de> from "Juergen Lock" at May 20, 95 02:31:02 am X-Mailer: ELM [version 2.4dev PL52] Sender: bugs-owner@FreeBSD.org Precedence: bulk > Hmm. my xterm termcap doesn't have a ti string... looks like vi > and bash, and definitely elvis (another vi-alike i happen to have > source around) all set keypad mode directly using the ks/ke strings. They aren't supposed to do this automatically; if they *do* do it automatically, then they are supposed to have a seperate internal token for the key, and decode it as if it were the numeric value. Look at the 'K' capabilities in the termcap database. > xterm|vs100|xterm terminal emulator (X window system):\ > :do=^J:le=^H:ho=\E[H:\ > :co#80:li#65:cl=\E[H\E[2J:bs:am:cm=\E[%i%d;%dH:nd=\E[C:up=\E[A:\ > :ce=\E[K:cd=\E[J:so=\E[7m:se=\E[m:us=\E[4m:ue=\E[m:\ > :md=\E[1m:mr=\E[7m:me=\E[m:\ > :ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kb=^H:\ > :k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:pt:sf=\n:sr=\EM:\ > :al=\E[L:dl=\E[M:im=\E[4h:ei=\E[4l:mi:dc=\E[P:\ > :MT:ks=\E[?1h\E=:ke=\E[?1l\E>:xn:\ > :AL=\E[%dL:DL=\E[%dM:DC=\E[%dP:\ > :hs:ts=\E[?E\E[?%i%dT:fs=\E[?F:es:ds=\E[?E:\ > :is=\E\E[m\E[?7h\E[?1;4l:cs=\E[%i%d;%dr:\ > :rs=\E[r\E<\E[m\E[H\E[2J\E[?7h\E[?1;3;4;6l: You notice that the ks/ke have \E[?1h and \E[?1l ? These are actually the codes for "application" mode, not keypad mode, and their effect is on the cursor keys, not the keypad keys -- hard to believe that they are supposed to be there. The Sun rs/is (as opposed to the xterm) actually contain \E> to forcibly reset from keypad mode. > so for vi/bash/elvis that means either patch sources or the ks/ke strings? The correct place to patch would be vi/bash/elvis, since the ks/ke are well documented and used. What you really need is the SCO, Informix, or TERM termcap, all of which have standard extensions to the 'K' values for handling keypad. You might also, if you have a Sun, want to look at the codes generated for the R1->R keys (the Sun keypad) and where they are coded in the termcap. > or am i still overlooking something... It's a vi/bash/elvis bug. The ks/ke is not supposed to be destructive, it's supposed to allow an application to distinguish the keypad and non-keypad characters with the same keycaps (in the case of the PC, when numlock is on). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.