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

[Vlad Harchev]

On Wed, 28 Jul 1999, Heather wrote:

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

 All are welcome to vote.
 
> 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?) 

 IMO it will be difficult to implement, and the functionality can be achieved
by pressing PgDn several times.
 
> 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.

 This patch has 'per text input' scope, not 'per form' (so *_TEXTINPUT is more
correct than *_FORM). And word 'ACTIVE_' is confusing (if there are ACTIVE,
then there are PASSIVE).

>[...] 
> I like!  I'd turn that on.

 OK, what other think about it (anyway I'll implement it, sooner or later).

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

 Seems not usual state (in this case user will be unable to edit text input
content), so special key like 'show_images' is required to make them editable
or not - seems inconsistent - so let they have boolean settings.
  
>[...]

> * Heather
> 

 Best regards,
  -Vlad