Re: lynx-dev Keys, an attempt to understand

[Klaus Weide]

> >     1.                  2.                    3.
> > 
> >     byte sequence  ---> lynxkeycode      ---> lynxactioncode
> >                                      (or ---> lynxeditactioncode)

On Wed, 10 Feb 1999, Henry Nelson wrote:
> 
> 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.

Yes, pretty much.  One could think of mapping byte sequence directly
to lynxactioncode, or to lynxkeycode and then checking everywhere
(well, mostly in mainloop) for a lynxkeycode isntead of for a
lynxactioncode etc., but that would be quite ugly and wouldn't allow
KEYMAP: configuration at all.

I remember that the first times I looked at that code, this two-level
procedure already looked confusing; so I was kind of answering my own
question here.

Now I think a big part of that was confusion was because the
lynxactioncodes are named LYK_* (with 'K' apparently standing for key),
while (some of) the lynxkeycode symbols don't have any "key" in their
name.

> > (8) DO_NOTHING is the "last" value in some sense.
> 
> I don't really understand why it must be "last".

It's just another thing that I had kind of assumed; there was some
code that depended on it when testing whether a lynxkeycode was within
the valid range.  Tom seems to have converted that to a test against
TABLESIZE(table), although there is still one
     if ((keysym > DO_NOTHING) || (keysym < 0))
in the for-slang code (it may be the right thing now, but have to
change if more general lynxkeycodes are added after DO_NOTHING).

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

I looked at an old lynx2-4-fm.zip - from not long before 2.5, I think -
the lynxkeycodes defined now, except for the recent MOUSE_KEY thing,
were all already there as today.  That means that in several years not
one new code was added for a real key.

Your concept, and more so J. Poons' ideas, now go to the other extreme -
instead of adding nothing, try to include everything.

Neither may be the best thing to do.  Some middle ground may be to
assign some keys, leave the possibility open to add more, reserve space
in some sense - something like that.

I suggest we should try to understand the reasons why things stayed the
same for so long.  We might find there are some good reasons, and should
then examine whether they still apply.  Anyone else up for some
speculation?

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

An external processor isn't necessary, and unrealistic to require
(especially for DOS, I would think).  But that mapping is already done
anyway by the various libraries - ncurses, pdcurses, ?? - as part of
the code linked into the lynx executable.  And then there is the
extension via the ".lynx-keymap" (for Unix at least) - It sounds like
you want to throw that out?

> Oh, do I love to jabber sometimes :)

Don't we all...

   Klaus