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

[Klaus Weide]

On Tue, 27 Jul 1999, Vlad Harchev wrote:
> On Wed, 28 Jul 1999, Klaus Weide wrote:
> > 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.
> 
>  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

I'd prefer something with "FIELD" in it.

> > 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...
> 
>  'textarea_drawn' is modified in LYUtils.c:highlight() - that's why it's
> global (in general I needed the way to invoke some code when current link is
> changed, so I placed it in highlight(OFF,....) and in the condition 
>  (curdoc.line != Newline) in mainloop, see below for more info).
>   Sorry for stupid prefix 'textarea_'.
> 
> > 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?
> 
>  Yes, they are. Firstly I added this functionality without those calls. But
> this has a very confusing visual effect. Since the text fields are highlighted
> not in LYUtils.c:highlight, removind 'redraw_only' argument and the logic for
> redrawing will make highlighted textinputs visually indentical to
> unhighlighted, so on page where textinputs come in chain, user will lose
> control on what the current link is (this looks very confusing, believe me).

Ok, I think I understand now (please correct if I'm wrong):
You want the field to have the same appearence as if one was line-editing,
even if one has not yet 'entered' the field.  This is to make clear which
is the 'current' link-or-field.

I didn't think of this.  I imagine though that having a 'not yet entered'
field appear the same as a 'field that is being edited' can also be
confusing in a different way.  Is there a way to visually distinguish
those last two cases?  (Maybe by the position of the text cursor?  Maybe
by statusline?)

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

I'm not sure whether this is good or not, for a field that isn't actually - yet 
-
being edited.  But since you have tried it and I have not, I have to believe 
you.
:)

> >    (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.
> 
>  Please expain (or  <some variable> will be equivalent in semantics to
> textarea_activated)?

No, <some variable> would just be the global setting that determines whether
auto-inputfield-entering (or however it is called) is ON or OFF.

But I realize now that, with that simple approach (if it worked), a current
input field that is not yet entered would look indistinguishable from non-
current ones - which you want to avoid.  So it can't be done this simply.

Except if we can use a different way to distinguish looks - see below.

sent expeditiously...

   Klaus