[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