Re: lynx-dev patch that allows text inputs to be non-sticky

[Klaus Weide]

On Mon, 26 Jul 1999, Vlad Harchev wrote:
> 
> * Added ability to make text inputs non-sticky (ie user will need to activate
>   them explicitly via and LYK_ACTIVATE action) - seems useful for people
>   navigating with alphanumeric keys. Default is 'sticky' - ie old behaviour.
>   Behaviour controlled via commandline option '--sticky-inputs' and
>   STICKY_INPUTS in lynx.cfg.

Comments:

1. This seems to be useful.  People have occasionally asked for it.

2. Please give this feature (and the option) a different name!

   To me at least, "non-sticky text input" doesn't mean anything.
   I had no idea what the patch was about from reading your message's
   subject line.

   better: "non-sticky text input *fields*"
   still better: something that avoids "sticky" altogether.  Not sure
   what, but "FLY_OVER_INPUT_FILEDS:YES" or "AUTO_ENTER_INPUT_FIELDS:NO"
   or "AUTO_LINEEDIT_INPUT_FIELDS:NO" seem preferable to me, maybe someone
   else has a better idea.

3. You introduce variables 'textarea_drawn' and 'textarea_activated', but 
   they seem to apply to text input fields in general, not just those for
   TEXTAREA.  Please avoid creating confusion.  If these variables are
   necessary, they should probably be 'inputfield_foo' or similar.

   Adding new global variables like 'textarea_drawn' should be avoided
   if at all possible, we should have less of them instead of more...

4. Are the 'redraw_only' calls necessary at all?  Have you tried what
   happens when the first change_form_link() (and surrounding block) is
   just skipped completely?

   (That would have been my first go - just add ' && <some variable> '
    to the condition in

            /*
             *  Normal, non-traversal handling.
             */
            if (nlinks > 0 &&
                links[curdoc.link].type == WWW_FORM_LINK_TYPE &&
                .....

    If you tried that, I would be curious why it wasn't enough.  Apart
    from use_last_tfpos not working, but then maybe it shouldn't if one
    doesn't want to automatically edit input fields.  keeping state in
    'textarea_activated' might not be necessary at all if this works.

5. This section:

        if (!(nlinks > 0 &&
              links[curdoc.link].type == WWW_FORM_LINK_TYPE &&
              (links[curdoc.link].form->type == F_TEXT_TYPE ||
               links[curdoc.link].form->type == F_TEXTAREA_TYPE)))
             /*
              *  Highlight current link.
              */
            highlight(ON, curdoc.link, prev_target);

    from the original LYMainLoop.c (and you haven't really changed it,
    except for adding braces) was inconsistent with other places where
    the link type is tested - the other text-like types should probably
    be added to the condition, I see now reason why there should be
    a call here to highlight(ON) for e.g. F_TEXT_SUBMIT_TYPE when it isn't
    done for F_TEXT_TYPE.  It doesn't seem to have done any harm.  But
    in case your 'textarea_drawn' was just introduce to deal with this
    inconsistency, you should get rid of 'textarea_drawn' and fix the
    inconsistency instead.

    It is my understanding that highlight() should never be called with
    ON for text input fields, only with OFF.  And this is already done
    in display_page for those fields.  Therefore my suspicion that your
    'redraw_only' call and keeping track of the displayed state with a
    'textarea_drawn' variable are only necessary with the effects of a
    highlight(ON) that should have been avoided in the first place.

6. This code could interact in some strange way with various mouse actions
   (clicking double-clicking if different, actions from ncurses-mouse
   menus, may act differently for F_TEXT_SUBMIT_TYPE than for other
   input fields), someone should test it...

7. Historical note, if anyone cares:
   This code reverts (optionally) to the behavior lynx seems to have had
   very early in its history.  From CHANGES2.3:

     1-13-94
     * slight change in forms user interface.  For the better, I hope you will
       agree.  Text input fields are now active as soon as the cursor pointer
       is over them.  Therefore you may begin typing into the text field
       as soon as you come to it.  Tab, and up and down arrow keys will
       move off of the text input field.  The only problem with this is as
       follows.  If you are in the habit of using the number keys (keypad)
       the or h,j,k,l vi keys, as soon as you move over the text link
       you will begin seeing numbers or hjk or l show up in the text field.
       In other words, your movement commands are now broken :(  You must
       use true arrow keys or the tab key to move off of the text field.
       I've tried this out and it seems to work alright.  I don't think
       that users unfamiliar with this will have too hard a time figureing
       it out.  Once you see numbers or letter appearing it becomes fairly
       obvious whats going on.  I'll put a message at the bottom of the
       screen saying "use tab or arrow keys to move off of link."

8. Some intermediate setting could also be useful: with that setting,
   once you have entered any input field for (line-)editing, lynx could
   assume you want to fill in forms and enter fields automatically as
   long as the same document is viewed.  (Just an idea, maybe not a useful
   one.  Of course this *would* require keeping more state, which I question
   for the current code.)


    Klaus