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

[Vlad Harchev]

On Tue, 11 May 1999, Keith Doyle wrote:

> 
> 
> Hi, 
> 
> I think I may have found a bug in KEYMAP handling.
> 
> I've never been quite satisfied with the choice of movement characters 
> in Lynx. In particular, I would rather the arrow keys all do what you 
> would intuit they do and that is to move up down left and right through 
> the active links. What the up left and right do bothers me a little,
> but the down drives me nuts.  
> 
> I see a link low on the page that I want to get to, and think
> "down" and hit the down key like I would in any other text oriented
> application I've ever seen, and find it instead goes to the right and 
> takes forever to get down to the link as it horizontally cycles through 
> 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 
> 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: 

 There was a suggestion (from Chuck Martin) to handle entry fields in a
special way - so that user will have to activate them to enter any text (so
it's possible to press any keys except the ones that activate links, and not
stick into entry fields). Perhaps it's worth implementing.
  
>       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.
> 
> After making the above change, when using enter in an input field, it does 
> the equivalent of a DOWN_LINK when it used to do the equivalent of NEXT_LINK.
> 
> So I thought, what would happen to Enter if you modified the down arrow
> to do something unrelated?  I then modified it to do a QUIT, and sure enough,
> when you hit Enter from an input field, it asks you if you want to QUIT. 
> This seems like a bug, as it makes redefinition of the down arrow key next 
> to useless.  I know that on some keyboards, the down arrow sends the same 
> code as Enter (Wyse 50? Wyse 60?  I forget.), but that seems like a poor 
> reason to impair the interface of the great majority of users out there 
> who are using terminals or terminal emulators that *do* differentiate between 
> the down arrow and Enter key, and both Terminfo and Termcap have unique
> definitions for the DOWN key.
> 
> Anyone else agree that this is a bug?
> 
> 
> 
> And while I'm at it:
> 
> Even if this Enter key side effect didn't occur, the UP_LINK and DOWN_LINK 
> functions themselves aren't quite what I'd like to see-- they have odd
> characteristics that seem to be defined by what was easier to program, not
> by what users would normally expect.  For example, given the following links:
> 
>        link_1 link_2 link_3 link4 link_5 
>        link_6 link_7 link_8 link9 link_10 
> 
> If you are on link_3 and do a DOWN_LINK, you end up at link_6 instead of 
> link_8.
> And if you are on link_8 and do an UP_LINK you end up on link_5 instead of 
> link_3.  DOWN_LINK from link_1 takes you to link_6, but up_link from link_6 
> takes you to link_5 so they are not inverses of each other as a user would
> normally expect.  Are there any plans to make any of these areas better?

 If there is a following situation,
        link_0
        link_1 link_2 link_3 link4 link_5
        link_6 link_7 link_8 link9 link_10
 and current link is link_6, you can move to link_1 by pressing UP_LINK twice,
then NEXT_LINK.
 

 IMO there is no deterministic algorithm to decide where to go in several
situations. For example,

 link1 A-link-with-a-very-very-very-very-very-long-highlighted-text link2
 link3 link4 link5 link6 link7 link8 link9 link10 link11 link12 ....
 
 What link should become highlighted after when the current link is
'A-link-with-a-very-...', and user command was DOWN_LINK?

 So, as Philip Webb suggested, the one of the reasonable way is using numbered
links. Another may be is using mouse (if lynx is compiled with ncurses, if OS
is linux, and if ncurses are compiled with gpm support, if -use_mouse switch
to lynx was specified and if you enjoy using mouse) :)
 
> 
> 
> Keith Doyle
> address@hidden 
> 

 Best regards,
  -Vlad