Date: Thu, 25 May 95 22:12:34 CEDT From: Juergen Lock <nox@jelal.hb.north.de> To: terry@cs.weber.edu (Terry Lambert) Cc: ache@freefall.cdrom.com, freebsd-bugs@freefall.cdrom.com Subject: Re: Changed information for PR misc/409 Message-ID: <9505252012.AA00108@jelal.hb.north.de> In-Reply-To: <9505201915.AA06222@cs.weber.edu>; from "Terry Lambert" at May 20, 95 1:15 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes: > > 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. This is also what i thought... > > Look at the 'K' capabilities in the termcap database. for digits? (and + - * / enter?) looks like there are none in 2.0R, at least not in the manpage. > > > 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. hmm. this is getting intresting... if i throw them out (ks=\E=:ke=\E>) then vi's and elvis cursor keys don't work anymore! (bash's still do) > > The Sun rs/is (as opposed to the xterm) (you mean this xterm termcap?) > actually contain \E> to forcibly > reset from keypad mode. no change if i add this. > > > 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. looks like vi and elvis actually use the ks/ke to get the cursor keys right and the non-working keypad is just a side effect of this... :/ > > What you really need is the SCO, Informix, or TERM termcap, all of which > have standard extensions to the 'K' values for handling keypad. looks so. and for the time being i just put this in .exrc: :map! ^[Op 0 :map! ^[Oq 1 :map! ^[Or 2 :map! ^[Os 3 :map! ^[Ot 4 :map! ^[Ou 5 :map! ^[Ov 6 :map! ^[Ow 7 :map! ^[Ox 8 :map! ^[Oy 9 :map! ^[Oj * :map! ^[Ok + :map! ^[Om - :map! ^[On . :map! ^[Oo / :map! ^[OM ^M > > You might also, if you have a Sun, want to look at the codes generated > for the R1->R<n> keys (the Sun keypad) and where they are coded in the > termcap. no Sun where i'm here, but it seems at least elvis wouldn't look for anything like this anyway. > > > 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). i think there is some confusion somewhere as to what the ks/ke strings really should do... thanx aynway, Juergen (now with a working keypad :) -- J"urgen Lock / nox@jelal.hb.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox ...ohne Gewehr PGP public key fingerprint = 8A 18 58 54 03 7B FC 12 1F 8B 63 C7 19 27 CF DA
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9505252012.AA00108>