lynx-dev Re: Keys, an attempt to understand

[Kim DeVaughn]

Thanks for the picture/model of keystuff that that you've drawn, Klaus.
It gives alot of insight as to the way things are done, to someone who
is new to the code, such as myself.


On Tue, Feb 09, 1999, Klaus Weide (address@hidden) said:
|
| Basically and "originally", we have two levels of mapping:
|
|       1.                  2.                    3.
|
|         byte sequence  ---> lynxkeycode      ---> lynxactioncode
|                                          (or ---> lynxeditactioncode)

| I leave out examples of deviations from the ideal here, as well as probable
| reasons for them and for the "accidental" properties.  We could get into
| that later.

By this, are you refering to cases where the "lynxkeycode" (or possibly
even the "byte sequence") are picked off for "special actions", and never
make it to the level-3 mapping?

For example, my own experience at an attempt to remap the ^W slot to
something other than LYE_NOP (which is an incorrect/misleading binding,
in and of itself), to a different "lynxeditactioncode" was unsuccessful
(^W still performed the REFRESH action).

I can't think of any good reason for such early pick-offs (though I
imagine there are some), but it certainly complicates the above model.


Also, while not any part of lynx, but the source of many *user* questions,
and/or frustrations, is the level  0 --> 1  mapping/filtering that you've
omitted, wherein the OS/shell/whatever picks off a keystroke/byte-sequence
for its own action, and never even presents it to the application (eg,
stty settings, etc).

Not strictly relevant to your discussion/model, but something that should
be kept in mind, nevertheless (ie, are there implicit assumptions about
whether the "byte sequence" lynx is getting is "cooked" or "raw"?).


| So I am not blaming anyone.  Instead the question is what to do now.
| I can see three possibilities:

I'll be interested in following the discussion that ensues ...

/kim