lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev A bug in the keymap handling?


From: Klaus Weide
Subject: Re: lynx-dev A bug in the keymap handling?
Date: Wed, 12 May 1999 06:39:35 -0500 (CDT)

On Tue, 11 May 1999, Doug Kaufman wrote:

> On Tue, 11 May 1999, Keith Doyle wrote:
> 
> > I think I may have found a bug in KEYMAP handling.
> 
> I don't think that this is a bug.

(I think it is, or at least it is a misfeature - see my other message).

> > the arrays of links that are on most pages.  So someone pointed out the '>' 
> > key which does more like what I want (not quite, but better than the default
> > down key).  I then find out that since it is a printable character, it has 
> > the side-effect of getting hung up when you encounter an entry field as it 
> > starts entering >>>>'s into the field.  So I looked into the keymap 
> 
> This doesn't have to do with being printable. Certain lynx keycodes
> are specially handled in the code and are not configurable. 

... and reducing special handling *where it is not necessary* would
be a worthwile goal...

> Only
> lynxkeycodes such as DNARROW will have their effect in text fields.

Lynxkeycodes whose lynxeditcode (in the Line Editor Binding) is LYE_CHAR
are interpreted as textual input.  that's more or less all lynxkeycodes
for printable characters.

> > configuration in the .lynx.cfg file.  I decided to try swapping the down 
> > arrow with the '>' key in the hopes it would fix the problem of 
> > encountering input fields while doing a down: 
> > 
> >     KEYMAP:>:NEXT_LINK     # Move to the next link 
> >     KEYMAP:0x101:DOWN_LINK # Move to the link below 
> >     
> > I'm using version 2.8.1rel2, and the above did work.  However it has an 
> > annoying side effect on the Enter key, which apparently is tied to whatever 
> > the DOWN key is configured to do and not to its own isolated function.  
> > And as far as I have been able to tell the Enter key does not have it's 
> > own keymap code.  In any event, I don't want to change the behavior of 
> > Enter, only of the down arrow.
> 
> This is tied to DNARROW, not to the key itself. 

What do you mean with "the key itself"?  I doubt that you literally
mean the key itself (the physical object which is part of Keith's
keyboard)...  You must mean some abstraction.

Of the different kinds of codes used for keys - native code[1],
lynxkeycode[2], lynxactioncode, lynxeditcode - which one represents
"the key" to lynx?  

[1] be that an escape sequence, a curses pseudo-character token,
    or some other code assigned by some library or driver - basically
    everything that is out of lynx's control.
[2] what lynx.cfg calls a "keystroke", and samples/lynx-keymaps calls
    a "keysym".

My answer is that the lynxkeycode is meant to represent "the key itself",
as far as lynx is concerned.  The native code is just a means for lynx
to know "which key".  (I say "as far as lynx is concerned" because
someone hacking ncurses or writing a terminal emulator will see things
in a different light.)

> DNARROW is defined in
> LYStrings.h. To do what you want, you need to switch the characters
> reported by the different keystrokes in LYStrings.c and recompile. See
> the examples there for the DOS port. How to do this, however, will
> vary according to whether you are using slang or ncurses.

I think you misunderstand what he wants.  He doesn't want to change the
mapping from native code to lynxkeycode.  That already works fine for
him as I understand.  The Enter key is recognized as lynxkeycode '\n',
the down arrow is recognized as lynxkeycode DNARROW, and typing '>'
is recognized as lynxkeycode '>'.  Any change along the lines you
suggest could only make this work less well.

   Klaus



reply via email to

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