Re: lynx-dev Link numbering and keypad mode

[Jacob Poon]

On Mon, 15 Feb 1999, Ismael Cordeiro wrote:

> On Mon, 15 Feb 1999, Jacob Poon wrote:
> 
> > > At this point in Lynx's development, I even wonder whether anyone still
> > > needs "keypad-as-numbers" mode. As an informal survey: who would
> > > currently be bothered if the keypad *always* acted as arrows, except
> > > when prefixed with "0" to make them into numbers?
> > 
> > I do. As a 101-key keyboard user, I always turned on numlock and I use the
> > keypad keys exclusively for numeric entries (at least for over 99.999% of
> > the time). If keypad keys can no longer be treated as numbers by default,
> > then I will definitely be annoyed.
> > 
> > Besides, under vt-100 terminals (at least on my terminal program), Numlock
> > key is used to toggle keypad keys between 'numeric mode' and 'application
> > mode'.
> 
> True VT100 terminals don't have a "numlock" key. It's the application that
> sets the keypad to numeric or application modes.

But then again, they have two sets of 'number keys' that can be
distinguished by the programs that support such terminals.

> > It is not beneficial for Lynx to force all 10 functions onto the keypad.
> > If I want keypad to behave like arrows, I just use the Numlock to toggle
> > it. There is no need to assign another key as the second Numlock.
> 
> Not all keyboards have a "numlock" key".

But then again, the terminal emulation programs that supports such
keyboards have software equivalent of 'numlock' built-in.  Whether it
actully assigns a key combo as numlock, or change it through terminal
settings, Lynx's 'second numlock' is not necessary. 

> > Therefore, there should be a third choice in 'Keypad act as' setting
> > called 'terminal specific'. This choice should allow 101/104/106-key
> > keyboards to toggle the functions of the keypad keys between cursor
> > movements (or 'application keys') and numeric entries, without Lynx to
> > override terminal settings.
> > 
> > BTW, this will also benefit 84-key keyboard users too, because their
> > keyboards will behave more closely to the terminals they choose.
> 
> Anda what about 91-key keyboards that are not IBM-PC keyboards? Not
> everybody uses IBM-PCs.

I think you did not understand my point here.  In case you didn't, let me
elaborate:

1. My suggestion is not specific to any hardware or software platform. 
The only hardware requirement is a keyboard with two sets of 'number
keys', one on the top of keyboard and the other at the keypad. 

2. I am not sure what 91-key 'non-IBM-PC' keyboards you are referring, but
I suspect they have their own keypads.  Anyway, if the keyboard is well
supported by the terminal program, then it should behave closely to the
terminal settings.

3. Even for keyboards without keypads (notably the sub-notebook market),
they may have their own cursor movement keys.

4. Lynx expects terminals to have some 'intelligence' (Lynx cannot run on
'dumb terminals').  Among all terminals, vt-100 is one of the
least-featured (if not the least-featured) terminals supported by Lynx,
and Lynx runs without crippling users by using keymaps with unsupported
key combo.

5. I did not say Lynx should only be optimized for certain kind of
keyboard, or certain terminal type, (except for dumb terminal, which Lynx
may never support).  What I do say in abstract is, to partially decouple
number keys on the keypad from the ones on 'typewriter keys', by offering
an option that allows user's terminal to do decide how 'number keys' to
behave.  More specifically, how the keypad keys behave, independently to
the 'typewriter keys' equivalent.

6. While it is true that Lynx should work on as many keyboards, terminals,
and OS as possible, Lynx should also take advantages of any new and old
devices it supports.  It seems to me that you believe by letting the
terminal itself to decide number key settings, Lynx automatically drops
support to old Lynx behaviours on numbered keys, but that is neither true,
nor what I have in mind.  On the other hand, if Lynx requires a user to
switch the number keys behaviour with the arbitrary '0' by default, it
penalizes everyone who has better keyboard(s), notably the users with
101/104/106-key keyboards.  And because such keyboard layouts have been
found on Mac, Sun, SGI, and even DEC/Boundless VT terminals (3x0 and up),
lacking a keypad decoupling option penalizes a lot of users, not just the
IBM-PC ones. 

Therefore, Lynx should add third keypad behaviour, 'terminal specific', to
allow users with better keyboards be more productive, not the other way
around.  It is important to treat it as an option, not a requirement, so
that if older keyboards do not behave as well as before under such new
Lynx settings, such users have a chance to operate their keyboards without
compromising efficiencies.