Re: LYNX-DEV ac98: 1.) configure,

[Michael Ritzert]

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