lynx-dev
[Top][All Lists]
Advanced

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

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


From: T.E.Dickey
Subject: Re: LYNX-DEV ac98: 1.) configure,
Date: Mon, 15 Dec 1997 05:33:01 -0500 (EST)

> 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.
what sort of software is that? (Ultrix?).  I'm curious what the curses
library looks like, and what the set of terminfo entries are.
 
>  > >  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 ).
I said 'probably' because I noticed in ncurses' terminfo that there's
two versions, depending on who wrote the description, and also because
there doesn't seem to be a well-defined rule about whether kf0 is F1 or
kf1 is F1 (I've been burned by that).  It really depends on who wrote it.
 
> 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.
well, I'm open to suggestions here - I've not studied Lynx to see how
we could extend that (it seems limited to the keypad on a vt220/etc, terminal)
 
> Michael
> 


-- 
Thomas E. Dickey
address@hidden
http://www.clark.net/pub/dickey

reply via email to

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