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

[Heather]

I have to admit, the idea of improving forms activity fascinated me, even
though the coding argument made me dizzy...

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

Vlad >  We can vote for reasonable name for this functionality (I don't 
     >  care what the name would be). I like the following:
     > AUTO_ENTER_TEXTINPUTS
     > STICKY_TEXTINPUTS

Can I vote?  I also agree, "sticky" is a suitable description for code, but
end users either won't grok it, or will confuse it with "sticky keys" somehow.

The real effect is whether a form on this page is "live" -- that is, wandering
down the page drops into the fields, or it (with this patch, as once upon a 
time it usually?) doesn't.  I can even imagine an intermediate state being 
introduced at some later point.  

Does this only affect text inputs?  I wouldn't mind being able to skip over
an entire form, including its radio bubbles and others - in fact that could 
be handled as jumping down to wherever the </FORM> was found... (I wonder how
it would handle borken pages with no close FORM tag?) 

So how about ACTIVE_TEXTINPUT: YES as default, NO as settable / commandline
tweakable.  Or if it covers entire form, please name it to make that clear --
ACTIVE_FORM: YES as default, NO settable / cmdline pickable.

> Adding 'redraw_only' argument took my time, but it was worth it. And if text
> in the input field is longer than input width, the input field will look like
> it's active (ie curly braces will be added, and the text will be scrolled to
> the end).

Sounds good, I think I can visualize it now

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

Vlad >  Keeping state in 'textarea_drawn' is necessary for the following reason:
     > the highlighted text input must be highlighted once,
     > after that any keystrokes should be interpreted as usual lynx 
     > keystrokes, not textinput keystrokes.

If I go to a modal behavior in my form or textarea I certainly want to know
when my keys are going to type and/or stay bounded, and when they're going to
do the usual lynx thing.

> > 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...
> 
>  Yes, I understood this when was writing.. Somebody should.

I've never used mousing in ncurses, I think.

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

Vlad >  May be (but that also should be configurable, otherwise we will go MS 
     >  way) - program thinks that it's cleverer than a user.
    >  I thought on adding another switch:
  > 
>  when in any textinput, pressing Arrow Left arbitrary number of times
> won't make previous document active (this annoys me too sometimes). What do
> you think? What the option name do you suggest?

I like!  I'd turn that on.

We really would be making the form modal at this point.  (Here's that
intermediate state already :> )  So same option name as suggested above, 
(ACTIVE_TEXTINPUT or ACTIVE_FORM) YES/NO upgraded to 
       MODAL           fields "sticky" - act like editor, not like lynx.
                       (pls make sure it's documented how to leave the field!)
       INPUT           (default) as they behave in release versions now.
       SKIP            fields are not considered worthy of stopping at.
                       They are still painted as plaintext.

Vlad >  And what those type of textinputs mean, can anyone explain:
     > 
     >  F_TEXT_TYPE         seems only 1 line of text
     >  F_TEXT_SUBMIT_TYPE  ?

Is this different from the submit button?  I know type="submit" can have
a value assigned in the HTML, which should be painted on the button, and
if a name= also given, submitted with all the other fields (so forms could
have three or even more buttons).  So maybe this exists to hold such 
name/value pair submit buttons ??

     >  F_PASSWORD_TYPE     content will be substitued with strars.
     >  F_TEXTAREA_TYPE     seems the same as TEXT_TYPE, but growable
     > 
     >  Did I understand those types correctly?

You match my understanding of using them as an HTML author.  (Though the
substitute with stars could be don't-display instead.)

Hmm, if the internal variables for forms all prefix F_, then F_ACTIVE would
be assigned the modal/input/skip detail, I suppose.

* Heather