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

[Klaus Weide]

On Tue, 11 May 1999, Keith Doyle wrote:

> 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: 
> 
>       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.  

Right (but only in that situation, i.e. when the Enter key is used to
get out of the Line Editor for a form field).

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

If anybody ever really wants to change the normal (not line-editing)
binding for the Enter or Return key, one of the following should work:

      KEYMAP:^J:...     or     KEYMAP:0x0A:...

or maybe, on some systems,

      KEYMAP:^M:...     or     KEYMAP:0x0D:...

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

That (if it is indeed the case) doesn't seem to have anything to do with
what Lynx does.  After all, in all other situations it distinguishes
between the two keys just fine.

> 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?

What's happening is
 1. Lynx gets Enter key in Line Editor (for form field), then looks at
    its (what I call) lynxeditaction (which is not modifiable by KEYMAP).
 2. the lynxeditaction code tells Lynx to exit Line Editor and return '\n'
    to main loop.
 3. Main loop converts '\n' to DNARROW.  This is coded as a special case,
    only applies on exit from form field editing:
                if (c == '\n' || c == '\r') {
                ...........
                    /*
                     *  Make return act like down-arrow.
                     */
                    c = DNARROW;

 4. Main loop goes on to look up binding for DNARROW in the usual way
    and act according to it.

The question is whether this is a hidden feature ("You can change the
effect of Enter in a form input field by mapping DNARROW") or a mis-
feature.  It is a misfeature in my opinion.  At least I cannot think
of any realistic situation where exploiting this hidden dependency on the
DNARROW mapping would be useful.  And your case - the only example I
have where someone actually wants to remap DNARROW - shows that it gets
in the way.

I think the only reason it was done this way is because it was the
simplest way, without breaking out of the normal main loop flow of
control with a goto or similar.

I have patches that change this (among other things), I'll send to the
list RSN.  Enter, when returned from the form field Line Editor, will
always act as NEXT_LINK (after other effects like submitting a single-
INPUT form or extending a textarea are taken care of).  This will not
be remappable, but I think it's good enough.

> 
> 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?

It may be simple to change the behavior to what you would expect as long
as both lines are one the screen.  I think it is non-trivial to make it
also work 'right' in all situations when UP_LINK or DOWN_LINK would
require going to the previous or next page.

As long as nobody takes on changing this for all cases, I would prefer
keeping the current behavior - unexpected at first, but entirely
predictable - over a changed behavior that would not always work as
expected.

   Klaus