[Top][All Lists]

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

Re: [Lynx-dev] backspace vs. delete can't have separate function

From: Thomas Dickey
Subject: Re: [Lynx-dev] backspace vs. delete can't have separate function
Date: Mon, 28 May 2007 10:55:53 -0400 (EDT)

On Mon, 28 May 2007, Rado S wrote:

=- Thomas Dickey wrote on Mon 28.May'07 at  9:05:50 -0400 -=

It seems that curses is returning ^H as KEY_BACKSPACE (0x107 is
0407 for which see curses.h rather than lynx.cfg's KEYMAP), which
lynx then translates into <delete> (see LYgetch_for()):

Argl, this means the only way to use both separately is to undefine
KEY_BACKSPACE or uncomment that code there?
Ugh, this doesn't even help: although it lists both with separate
functions, still the BS key doesn't produce the HISTORY function
as desired but some DOWN_LINK.

GETCH: Got 0x107.
LYReadCmdKey(0) -><delete> (0x7f)

Uh, here it produces this:
GETCH: Got 0x107.
LYReadCmdKey(0) ->End (0x107)

Is this "normal" or even "ok"?

It doesn't look right - that looks as if it's not seeing the KEY_BACKSPACE
case and is returning Lynx's code.

It-would-be-nice if Lynx used curses codes more than it does,
e.g., so it didn't have its own meaning for 0x107.  It does
that for a couple of reasons: a lot of the keyboard code was
contrived to work with VMS curses, and then hacked up for slang...

BTW, what kind of codes >0xFF are those?
I know they are "function keys", but how are they translated?
How do they relate to literal chars pressed or terminfo?

it's written down in lynx.cfg (but as noted above, curses and slang
have their own codes which lynx first translates into its own):

I've seen the list before, I wasn't looking for the literal
translation, but rather why and how this happens the way it happens
with ncurses.

For ncurses, I assume it happens because there's a "kbs=^H" in the terminal description...

Thomas E. Dickey

reply via email to

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