[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev Keys, an attempt to understand
From: |
Henry Nelson |
Subject: |
Re: lynx-dev Keys, an attempt to understand |
Date: |
Wed, 10 Feb 1999 18:11:10 +0900 (JST) |
> 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
- Re: lynx-dev Keys, an attempt to understand [PATCH], (continued)
lynx-dev Re: Keys, an attempt to understand, Kim DeVaughn, 1999/02/10
Re: lynx-dev Keys, - a correction, Klaus Weide, 1999/02/13
Re: lynx-dev Keys, an attempt to understand, Lloyd G. Rasmussen, 1999/02/10
Re: lynx-dev Keys, an attempt to understand,
Henry Nelson <=
Re: lynx-dev Keys, an attempt to understand, Henry Nelson, 1999/02/10
Re: lynx-dev Keys, an attempt to understand, dickey, 1999/02/10
Re: lynx-dev Keys, an attempt to understand, Henry Nelson, 1999/02/15
Re: lynx-dev Keys, an attempt to understand, dickey, 1999/02/15