[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: curses vs. xterm key mismatch
Re: curses vs. xterm key mismatch
Mon, 16 Apr 2007 15:59:50 -0400 (EDT)
On Mon, 16 Apr 2007, Will Parsons wrote:
Thomas Dickey wrote:
On Fri, 13 Apr 2007, Will Parsons wrote:
I'm working on a curses application that is supposed to react to an End
key, but this does not seem to be recognized in a xterm under FreeBSD 6.1.
Investigation shows that when I press either of the End keys, what curses
sees is 0601, which seems to be defined as KEY_SELECT in curses.h. (There
is no problem running under a real console.) Is this an xterm issue, a
terminfo issue on FreeBSD, or something else, and what is the best/proper
It's a limitation of the way any version of curses works.
They use the first keycode in their table which is assigned to a given
string. Since xterm is emulating a vt100/vt220, that means it's thinking
of KEY_SELECT rather than the PC-style Home/End. You can switch the
terminal description and get a different behavior.
Thank you for your explanation but I'm still a bit confused. Does that
mean that when I hit the End key on a PC keyboard, that sends the same
escape sequence as would a Select key on a real vt100, so that what I am
seeing is in a sense legitimate? I don't quite understand what you mean by
yes - it is legitimately sending the same escape sequence.
(btw - vt100's are a subset of vt220 - vt220's have the Select key, but
"switch the terminal description" - is this something specific to FreeBSD
that I would have to ask on a FreeBSD newsgroup?
no, I just meant to either use a different setting for $TERM (simple),
or to use a new termcap/terminfo (complex).
A quick check shows I'm using the PC-style in xterm's terminfo.
Ditto for ncurses. FreeBSD has its own termcap (though I recall
its xterm entries being modified to match ncurses a couple of years
ago). But it could be either flavor - or both. At one point both
definitions were in the terminal description, but since curses uses
only one, I removed the one that was less useful. If your terminal
description has both, curses will use the first one in the table,
(looks like KEY_HOME would override...)
way of handling this? (Obviously, I can have my program simply look for
KEY_SELECT in addition to KEY_END, but this doesn't seem right to me.)
I'm still unsure of what I should be doing - complaining to FreeBSD that
something is wrong with their termcap/terminfo, making some sort of
adjustment in my environment, or simply accepting that KEY_SELECT may do
the same as KEY_END and allowing for that in my application?
At the moment I'm looking at the FreeBSD termcap, which appears to be
using for "xterm" the entries that I had updated for XFree86 in 2001.
That was imported into FreeBSD in 2002/08/27.
That particular file is hand-maintained, though I generate a termcap.src
from ncurses' terminfo.src periodically. Checking now, I see that xterm's
termcap file still uses Select as well as End (does not cancel one in
favor of the other, but just adds them both). But the intent of that file
is not to support curses applications, just low-level termcap applications
(though that's what FreeBSD used it for ;-).
For terminfo, I canceled the conflicting keys from the descriptions
a while back (and those are PC-style, with a comment in the terminfo
file indicating how to change the entries to vt220-style).
So - using the termcap entry for curses means you'll get one set of
keycodes, but using the terminfo entry means you'll get a different set.
Thomas E. Dickey