Re: lynx-dev Keys, an attempt to understand

[Jacob Poon]

On Wed, 10 Feb 1999, Henry Nelson wrote:

> > I can see three possibilities:
> [...]
> > 2.) Add another mapping level, those new codes -> lynxkeycodes.
> > 3.) Keep on identifying those new codes == lynxkeycodes, but make
> >     it work consistently somehow, and spell out the new rules.
> >     At least this seems to require moving the traditionally assigned
> >     lynxkeycodes from 0x100 to some other area, or use some offset for
> 
> My concept is that there "ought" to be a table which can hold at least
> 424 (106 keys x 4 variations [alone, shift-, ctrl-, alt-]) keystrokes
> with mappings to 1272 actions (424 keystrokes x 3 modes [browser, dired,
> text editor]).  The table theoretically would be dynamically allocated
> when Lynx starts up so as to not waste memory, according to compile-time
> defaults or user configurable tables in lynx.cfg.  I don't think Lynx
> should or needs to do more than this, i.e., level 2 ==> 3 mapping.

424?  Isn't this too limited?  Even DOS machines had added a few more
modifier keys recently.  It will be bettter if Lynx can accept actions
that use several modifier keys at the same time, so that Lynx will not
run out key maps so easily as it currently does.

To make code optimizations and handling easier, Here is one proposal:

During translation from byte sequence to lynxkeycode, the Lynx key code
table uses 8 least significant bits to map each physical key on the
keyboard.  However, leaving 3 'keys' as 'unrecognized', 'no key
pressed', and 'extended key'. 

The higher significant bits are used to represent modifier keys (ctrl,
alt, shift, etc.), as well as keyboard states (caps lock, num lock, scroll
lock, insert state, etc.).  This area should occupy minimum of 16 bits,
with 1 bit for each state/modifier.

The encoded value as follows:

xxxxxxxxxxxxxxxxyyyyyyyy

x=modifier bits, y=key value

Byte ordering uses big-endian.

To decrease unnecessary memory for processing lynx key code into lynx
action code, L2 encoder pack each lynxkeycode into variable length value.
The L3 decoder will then read off the stream of packed lynx key codes
directly.

When no modifier keys are turned on, L2 encoder just strips the modifiers
and level 3 decoder can process in byte-per-byte basis.  When modifier
keys are used, L2 bytes send the 'extended key' byte value to indicate
modifier key(s) is used, then sends 'modifier bytes' along with actual
'key value'. 

So, the L2 encoder generates one of the following codes for each key
combination:

yyyyyyyy  if no modifier;
11111111vvvvvvvvxxxxxxxxxxxxxxxx.....yyyyyyyy  if modifier is used.  Note
that byte value 0xFF is assumed as the 'extended key'.

The 'v' bits tells L3 decoder how many bits are used as modifiers. 
Modifiers are encoded in network byte order (big-endian), because it will
allow data to be packed further, by allocating less frequently used
modifiers as 'most significant bits'. 

This system allows maximum 255 modifier keys to be used at the same time,
which is more than enough in any forseeable future.