Re: lynx-dev Keys, an attempt to understand

[Henry Nelson]

> Basically and "originally", we have two levels of mapping:
> 
>       1.                  2.                    3.
> 
>         byte sequence  ---> lynxkeycode      ---> lynxactioncode
>                                          (or ---> lynxeditactioncode)

Thanks much!  This is a lot like how I vaguely was "seeing" things.

> Is this two-level procedure necessary, or is it already too
> complicated in principle?  I say it is A Good Thing, and think that

I don't know about "good" so much as, "how else" could it be done?
Seems like a necessity.

> (8) DO_NOTHING is the "last" value in some sense.

I don't really understand why it must be "last".

> 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.

1 ==> 2 mapping "should"/can already be done outside of Lynx.  For DOS,
perhaps other OSs, it might require a kind of front end processor to be
installed as a device since most users would not be able to patch the
kernel.

Oh, do I love to jabber sometimes :)

__Henry