lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ilya Zakharevich
Subject: lynx-dev Re: Changing the keymap code (PATCH)
Date: Sun, 7 Feb 1999 14:11:40 -0500

On Sun, Feb 07, 1999 at 07:54:35AM -0800, Kim DeVaughn wrote:
> See the thread 'Nitsy "reset" display buglet', and the subthread
> '[dev15] patch for mouse key buglet' for the background details
> (all messages posted on 02/05/99).

Drat, please ignore my previous reply about removing the shift by
removing LYK_DO_NOTHING.  It is probably broken.

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

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.

There is a table of possible Lynx actions.  MOUSE_KEY is a possible
lynx action (perform the action appropriate for the current mouse
press).  Why the table of *possible* lynx action should be system
dependent?  OK, some of actions may be not available (i.e., not bound
to actual keypresses) on some platforms.  But why not have them all
defined in a uniform way?

I needed to add a new action (MOUSE_KEY).  I did it like this:

@@ -84,7 +89,12 @@ extern char * SNACat PARAMS((
 #define SELECT_KEY       267  /* 0x10B */
 #define INSERT_KEY       268  /* 0x10C */
 #define REMOVE_KEY       269  /* 0x10D */
-#define DO_NOTHING       270  /* 0x10E */
+#define MOUSE_KEY        270  /* 0x10E */
+#define DO_NOTHING       271  /* 0x10F */
+
+#  define FOR_PANEL    0
+#  define FOR_CHOICE   1
+#  define FOR_INPUT    2
 
 #define VISIBLE  0
 #define HIDDEN   1

The only side effect I can see is that DO_NOTHING moved.  Probably it
could break zillions of other things, which somehow depended on the
particular value of DO_NOTHING (like other tables fixed in your patch).

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.

Ilya

reply via email to

[Prev in Thread] Current Thread [Next in Thread]