Re: lynx-dev non-sticky text inputs

[Heather]

> On Wed, 28 Jul 1999, Heather wrote:
> 
> > 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.

Ok, I amend this, to whether TEXT flavored parts of forms are "live", etc.
Making whole forms dead or live would be a fresh topic, after this one's 
settled in.

> > Does this only affect text inputs?  I wouldn't mind being able to skip over
> > an entire form, 
> 
> That would be a completely different feature, and probably not very
> useful for FORM in the general case.  A key for "going to the next Hn
> heading" would probably be more useful, and about as difficult, but useless
> for the may pages that don't use <Hn> in a logical way.
> 
> There are many theoretical "go to the next X" key commands that could
> sometimes be useful, none of them so generally useful that it would be
> worth starting to assign keys to them, IMO.  And one for X == <FORM> or
> X == </FORM> would be among the less useful ones.

You're right, skip-keys (especially when we have a key overload problem
already) are not useful enough to code up at this point.  That's what I get
for writing off-the-cuff.  Blow it off for now.

> [ Maybe I snipped too much - it wasn't clear to me which of the snipped
> text is relevant to the following ]
> 
> > We really would be making the form modal at this point.  
> 
> Could you please give a definition for "modal"?
> 
> I have seen the term, have kind of a fuzzy understanding of it, but
> it doesn't seem to match your use.  (According to my fuzzy understanding,
> all lynx user interaction is "modal".)

vi is modal, in that there is an input mode, where all your typing does
well, input, and very few keys do something unusual (such as ^v allowing
entry of fancy keys, and escape leaving the mode).  There is of course also
the command mode, where almost nothing generates input, and those things that
do only do it out of prepared data (such as Y filling the buffer with a Yanked
line, and p p)utting it into the data being edited).

In the land of MS windows it's very common to have dialogs be either 
application modal (the regular app commands are suspended and inaccessible
until you answer this, but you can task away to some other app, then back 
again) or system modal (this dialog has grabbed input focus, so no other 
mswin events will see inputs from keyboard or mouse until you answer this).
We don't have anything resembling system modal in the way lynx is used.  

But we do have app modals already: when I'm on a pickfield in its normal
state, left arrow takes me to previous page, home/end take me to top/bottom
of current rendered page respectively.  But when I've pressed enter on a
pickfield, it's modal... home/end go to the top/bottom of the list, not
outside, and left arrow merely closes the field again.

Setting the "pop-open text fields" option would provide similar modality
to textfields.

> > (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!)
> 
> I don't understand what this means.  "Act like an editor" - in which respect?

Okay, let me describe by example.

I have "pop-open textfields" on.  I meander down a page with lots of text
fields, assume happily with vi-keys now that they don't become text inside
the fields.

I arrive at a field I want to fill, I hit (whatever assigned key) to pop it
open (maybe it draws cute little line box around it).  I am now in a mode
where (I hope) arrow keys travel around my text allowing me to correct 
misspellings, maybe a compose key exists or not, backspace eats keys I
just typed, etc.  Like an editor.  Also like (my favored editor) I hit
(whatever assigned key) to leave this pop-open field, accepting its content.
Maybe I also have some means to bail, and not accept what I have just
wrecked, but I'd consider that an enhancement - don't worry about it yet.

Key to get in, and key to get out, must be assigned.  Enter is an okay 
choice for single lines, but terrible as exit key for textarea fields,
since it's pretty common to want to do a paragraph or two in those.  I'm
sure that's all been argued out on entirely different threads before.

> >        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?
> 
> As an example, go to <http://www.freshmeat.net/>.  Move to the
> only input field, type "lynx" then enter.  "It submits", although
> there is no submit "button".

So this F_TEXT_SUBMIT_TYPE is used by lynx on a text field when there's
no submit-button.  What if this weenie's form has more than one text
field?   (this is all a sideline, though.  No particular relation to
pop-open text fields, except that they might also have to be submitters,
so that shouldn't get broken.)

> Incidentally, this field also shows the effect of highlight(ON)
> as a sometimes visible flicker, when moving onto the field.
> (It may only be noticeable because I have changed COLOR:6 to use
> a different background from that for COLOR:0 and COLOR:1; I have
>    COLOR:0:black:white
>    COLOR:1:blue:white
>    COLOR:6:lightgray:red
> using slang.
> 
>    Klaus

There being only 8 colorsets so far (0-7) it should be easy to make them 
all look quite different, for testing...  yellow on brown, brightcyan on
blue, white on black, etc.

* Heather