bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Multiple bindings for the same keycode


From: Avery Pennarun
Subject: Multiple bindings for the same keycode
Date: Thu, 17 Aug 2006 02:16:56 -0400

Hi all,

I'm currently attempting to find a way to create a "super" terminfo
entry that works (perhaps with non-optimal amounts of output) on as
many terminal types as possible.  There are two parts to this: use
fewer different kinds of output codes (eg. so Windows 9x telnet won't
get confused), and accept multiple different bindings for the same
special key (eg. Home has various different possible values, even
among the various so-called VT100 compatible terminals).

I might send a message about the first issue another time, as I think
I might have found a bug in ncurses 5.5 if you disable all of cub1,
cuf1, cuu1, cud1 from a terminfo entry and leave only cup: cursor
positioning doesn't quite work reliably in that case, even in a
sensble terminal like xterm or rxvt.  However, I don't have a simple
test case for this yet so you might find it hard to debug.

Meanwhile, I need some advice on how to implement my second problem
relating to keycodes.  My initial implementation looked something like
this:

- split keycode strings on the string "!!" and call _nc_add_to_try
once per portion of the split string
- modify tic and infocmp to parse/dump a file with more than one
"khome" (say) and produce an output file with a single entry separated
by "!!".

This actually works really nicely for most apps, and I was happy with
the results.  Unfortunately, it seems that some apps try to do more of
the work themselves, and ask for the actual key string from ncurses...
and this includes the "!!" and extra crud, so such apps don't work
right at all.

Looking at the source code for these (like joe, Joe's Own Editor), it
seems that they all implement their own key lookup tree and assume
that strings to keycodes is a 1:1 mapping, so at best, unless patched,
these apps can only degrade gracefully into "normal" ncurses 1:1
keycode behaviour.  However, most apps aren't in this category, so as
long as we don't make these apps *worse*, many other apps will benefit
automatically from ncurses supporting the extra keycodes.

But the problem is that my clever plan to overload the meaning of
"khome" and friends by splitting on "!!" is apparently too hacky to
work.  Where else in the termcap can we put the extra keycode
information?

My current patch (with the "!!" splitting) is attached, for reference.

Have fun,

Avery

Attachment: patch
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]