FW: [TF] Bindings and compatability... This may have been coveredbefore..

[naked at iki.fi (N. Kotivuori)]

Kyle Stone wrote:
> I've had this problem on FreeBSD and TinyFugue ever since I started
> using X.  The vt220 console(not the cons25) works flawlessly with
> the /etc/termcap info.. You can use either the cons25(sco) or the
> vt220 with a kernel option in FreeBSD.  This is a default FreeBSD
> 4.7 release.  I've tried gnome-terminal, xterm, and
> multi-gnome-terminal..  This is with multi-gnome-terminal here...
> 
> By looking at /etc/termcap...
> xterm|vs100|xterm terminal emulator (X window system):\
>         :ut:li#24:\
>         :kh=\EOH:@7=\EOF:kb=^H:kD=^?:\
>         :k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:km:\
>         :is=\E>\E[?1;3;4;5l\E[?7;8h\E[1;65r\E[65;1H:\
>         :rs=\E>\E[?1;3;4;5l\E[?7;8h:\
>         :tc=vt220:

xterm is the wrong terminal type for all those terminal emulators. It
will not work. Also, looking at /etc/termcap is not reasonable, since
it is not used. With a recent ncurses, terminfo is used. You will have
trouble finding the utilities on FreeBSD I think as they are not built
by default, but saying 'infocmp xterm' should give you the correct
one. You can pass also several terminal types to infocmp and it will
do a comparison between them. It is educational to see how much indeed
differs between xterm and rxvt and gnome-terminal.

> So presented with this.. One would assume the following would work: /def
> -b'^[OP' KP_1x = /echo 1xterm /def -b'^[OQ' KP_2x = /echo 2xterm /def
> -b'^[OR' KP_3x = /echo 3xterm /def -b'^[OS' KP_4x = /echo 4xterm

Um, I think you are misunderstanding something. 'k1', 'k2', 'k3', 'k4'
are the function keys, F1, F2, F3, F4 in termcap. 'K1' on the other
hand (notice the case) is the top-left key of the keypad (the one with
'7' and 'home' on it). But this is all termcap capabilites. For
terminfo, the capabilities are 'kf1', 'kf2', ..., and such. You can
look these up from 'man 5 terminfo'.

> However in TF my 1 on the kp presents me with a ^[OF which I can
> bind on and test to be true with "/def -b'^[OF' KP_1v = /echo v1"
> And [OF happens to be reproduces by my end key on my regular
> keypad.. Anyone have an idea?  I'm going to go grab the latest
> ncurses but 4.7 is pretty new and this has been going on for
> years.. For me atleast.

The keypad is really tricky to bind properly. The problem is that in
general, they keypad arrows and end, home, pg up, pg dn keys should
behave either exactly as the main keyboard keys - or as simply number
keys. You can alleviate this fact a bit by switching between
'application keypad' and 'application cursor' in xterm - then the
terminfo entries are correct, but keypad is indistinguishable from the
main keyboard.

The best way to get keypad events completely separate from other
keypresses is to switch xterm into vt220 mode and then use the
'xterm-vt220' TERM. Then, if the keypad is in application mode, the
keys produced are unique. You can find these keys out by either
testing the output or looking at the 'ctlseqs.ms' in the xterm
distribution for their definitions. But unfortunately there are no
terminfo entries for such behaviour, so there's no automatic
determination of the keycodes there - you have to match them manually
against the terminal type.

> Also, a quick remedy.. Can anyone give me an example of how to use
> keycode to get the what TF "thinks" things are? I thought "/test
> keycode(KP1)" would do it, but I was wrong.

/result keycode("KP1")

try something like:

/result keycode("Down")

as well to make sure you get atleast something, since the KP1 entries
can be empty if the terminal doesn't specify them (for example when
running under screen).

***

So, summa summaarum, you can get this stuff to work, but it's not
always easy. You need to be a bit more specific about what keys
exactly do you wish to work and how and what keys need to be
recognized separately from other keys to be able to get specific
answers on what you need to tune.

-- Naked