[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LYNX-DEV ac98: 1.) configure,
From: |
Michael Ritzert |
Subject: |
Re: LYNX-DEV ac98: 1.) configure, |
Date: |
Mon, 15 Dec 1997 10:02:50 +0100 |
T.E.Dickey writes:
> > >#define KEY_F(n) (KEY_F0+(n)) /* Space for 64 function keys */
> > >#define KEY_SELECT 0601 /* select key */
> > >#define KEY_FIND 0552 /* find key */
> > >#define KEY_IL 0511 /* Sent by insert line. */
> > >#define KEY_IC 0513 /* Sent by ins char/enter mode
> > >key. */
> > >#define KEY_DL 0510 /* Sent by delete line key. */
> > >#define KEY_DC 0512 /* Sent by delete
character key. */
Thomas: the terminal i am testing this is a vanilla dec vt420, set up
to "vt400-mode, 7 bit controls", "8 bit characters", "application
cursor keys", "terminal id vt320".
I'm running this terminal over an old dec terminalserver over lat to a
vax (6410) which runs captive telnets to the linux machine running
lynx (i will be get the allowance to run lynx directly on the vax). on
linux, TERM is detected to be "vt300". My terminfo will use the vt320
entry since vt300 is linked to vt320.
> >
> > I added cases for KEY_SELECT, KEY_FIND, and KEY_IC to the devel
> > code and tried it on Scott's SPARC, and SELECT_KEY, FIND_KEY, and
> > INSERT_KEY now work, but case KEY_F(16): doesn't work for DO_KEY. I
> > used Scott's native curses, not ncurses, but is the problem in his
> > terminfo, or is 16 the wrong number? REMOVE_KEY works without need
> > for a case. Is that because there's no keypad() mode mapping for it
> > so the escape sequence is used directly in LYgetch()?
> Numbering probably starts at 0 for internal KEY_F(n) codes (I'll have to
> look at
not just probably but exactly. I knew of these additionally needed
function key definitions and had indeed put them into LYgetch() at the
time of writing my posting. It works fine for me but i find the
solution unelegant: the code to treat some vt320 escape sequences is
already there but not reached under ncurses ( libncurses.so.3.0 ).
The main disadvantage of my present "solution" is that the additional
function keys cannot be remapped (despite possible incompatibilites to
other versions of curses which i cannot test?). Simply extending the
jump table use for keyboard remapping will lead to a large table of
entries most of which are unused. I consider it very important to be
able to define keys freely, in the case of function keys much more
than elsewhere. At present i am trying to get the "feeling of the user
interface" right for our All-In-One/WPSPLUS - users, but that will
probably not everyone's taste.
Michael