lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev [PATCH 2.8.3.dev10] Key binding in lynx


From: Klaus Weide
Subject: Re: lynx-dev [PATCH 2.8.3.dev10] Key binding in lynx
Date: Wed, 10 Nov 1999 04:25:06 -0600 (CST)

My comments without testing.

On Wed, 10 Nov 1999, Ilya Zakharevich wrote:

> The following patch allows arbitrary key bindings in lynx.  The next
> step is (of course!) how to merge different ways to bind keys into one
> command.
> 
> I have this
> 
> setkey "\200s" LAC:LEFT_LINK/BACKW     # C-left
> setkey "\200t" LAC:RIGHT_LINK/FORWW    # C-right
> 
> in my .lynx-keymaps file, and C-left/C-right move by word in editing
> modes, and move to left/right link in "principal" mode.

(Your patch is missing comments added to samples/lynx-keymaps.
we don't need yet more undocumented keymapping features...)

This should be done at the lynx.cfg KEYMAP level, not at the
.lynx-keymaps level.  Or at least, it should be done *primarily*
at the lynx.cfg KEYMAP level.  The LAC: stuff in .lynx-keymaps
shouldn't be encouraged (as I wrote there, "should [thus] be used
sparingly).  Not everyone uses .lynx-keymaps, not everyone should
have to use it to get your useful extension, on some systems (DOS etc./
non-ncurses curses) .lynx-keymaps just doesn't make sense or is not
implemented (USE_KEYMAPS undefined).

The more general (and logical) way would be to extend the meaning of
the added last field in KEYMAP, which currently only understands PASS.

> [Patch is agains dev10, but I do not remember any obviously conflicting 
> patch.]

Have you checked the patch in
   Linkname: lynx-dev patch - Referer with query, un-hardwire ^Ve, 
PERSISTENT_COOKIES
        URL: http://www.flora.org/lynx-dev/html/month1199/msg00048.html

I have another patch in the works, (based on that one).  Among other
things, it extends the last KEYMAP field so it can contain "DIRED",
for changing the Dired 'key_override' table rather than the normal
'keymap' table.  I guess that would be compatible for using the field
also for Line Editor bindings: there are never form fields in Dired
mode, so it wouldn't make much sense to specify a "Line Editor binding
to be used in Dired".

I hope you could revise your patch after mine is out, so they can
work together...

>  
>  /* * *  LynxKeyCodes  * * */
> +#define LKC_ISLAC2   0x8000  /* flag: contains 2 lynxactioncodes */

I guess that should be LKC_ISLACLEC (or LKC_ISLECLAC)...

> +/*  Substitute a single actioncode given a double one */
> +#define LKC2_TO_LKC(c,n)   (((c) == -1 || !((c) & LKC_ISLAC2)) ? (c) : \
> +                         ((n) == 1) ? (((c) & LAC_MASK) | LKC_ISLAC) : \
> +                         (((((c)&~LKC_ISLAC2)>>LAC_SHIFT) & LAC_MASK) | 
> LKC_ISLAC2))

.. and this one [???] ...

>  /*  Mask lynxactioncode as a lynxkeycode.  */
>  #define LAC_TO_LKC0(a) ((a)|LKC_ISLAC)
> +
> +/*  Mask 2 lynxactioncode as a lynxkeycode.  */
> +#define LAC2_TO_LKC0(a,b) ((a)|((b)<<LAC_SHIFT)|LKC_ISLAC2)

... and this one LACLEC_TO_LKC(0?). 

> +
> +  {"FORM_PASS",      LYE_FORM_PASS,  "In fields: input complete, or Do 
> Nothing"},

How about just

     {"PASS",      LYE_FORM_PASS,  "In fields: input complete, or Do Nothing"},


General comment: well I'm glad to see my bitmappification of key
codes hasn't scareed everyone off, apparently it still makes sense
to someone... :)


  Klaus


reply via email to

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