lynx-dev Re: Changing the keymap code (PATCH)

[Kim DeVaughn]

On Sun, Feb 07, 1999, Ilya Zakharevich (address@hidden) said:
|
| > Basically, there was a define for MOUSE_KEY added in LYStrings.h
| > for the -dev.8 release, which resulted in the observable behavior
| > of the statusline getting blanked out when a reset button or select
| > was activated.
|
| I still do not know what you are talking about, since my keymap shows
| nothing related to reset (except CHANGE_LINK, which is not bound) or
| select (except the strange keyname "Select key").

Well, let me repost the analysis that Klaus posted, which led immediately
to the solution/patch that I posted (which others tell me causes problems
for DOS):

 => LYStrings.h has changed from
 =>
 =>    #define DO_NOTHING      270     /* 0x10E */
 => to
 =>    #define MOUSE_KEY       270     /* 0x10E */
 =>    #define DO_NOTHING      271     /* 0x10F */
 =>
 => but the tables in LYKeymap.c where not kept in synch with this change,
 => as a result of this the
 =>
 =>            cmd = keymap[c+1];
 =>
 => in mainloop() now maps DO_NOTHING to 0 instead of LYK_DO_NOTHING,
 => which in turn leads to first writing the (wrong) statusline, then
 => comes the refresh because of refresh_screen which erases the screen,
 => and then a new statusline is not written because we already did it...
 => all in a quite non-obvious manner which may be worth cleaning up in
 => mainloop(), but I suppose fixing the key mapping will restore the
 => previous behavior.

The key phrase being "not kept in sync".

While your adding the def for MOUSE_KEY has nothing to do with reset or
select per se, doing so created that problem as a *side-effect* (and
perhaps other problems as well, which have yet to surface).


| Here is the problem as I see it:  the lynx keybinding scheme is too
| baroque for anybody to understand.  It is driven by tens of
| interrelated tables without any clear documentation which tables does
| what.

I agree.  Keybinding should be consolodated, and rationalized.  I find
it quite annoying that some keys are picked off early in the food chain
for special purposes, and cannot be rebound at the user level.

Or for that matter, at the compile level, in some cases.  For example,
why *must* I have a ^W refresh the screen, when I have ^L to do that?

When I added the alternate line-edit bindings, I wanted to rebind ^W to
do something else, but doing so in LYEditmap.c did not work ... ^W would
*still* cause a screen refresh, even though (supposedly) rebound.  Etc.


| Then this need to be changed, since MANY other actions need to be
| added to lynx (SAVE_DOCUMENT, DOWNLOAD_BY_METHOD_4 immediatedly come
| to mind).  So here is my question: what is the "correct" way of adding
| a key-action to lynx.

Ah.  The $64,000 question ...

However, for the moment, what is needed is a solution to the problems
created by the addition of MOUSE_KEY, which will be acceptable to all
the various build/platform flavors supported.

/kim