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 Tue, 27 Jul 1999, Vlad Harchev wrote:
> > >[...] 
> > >  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.
> 
>  But seems that the word TEXT should be in it too (otherwise INPUT can mean
> checkbox if html INPUT tag is in mind).

Yes, that makes sense.

>  And we should think of the corresponding name for commandline option (IMO it
> shouldn't be that long).

AUTO_ENTER_TEXT_INPUT_FIELDS
AUTO_ENTER_TEXT_FIELDS
AUTO_ENTER_TEXTFIELDS
DONT_ENTER_TEXTFIELDS_UNTIL_I_SAY_SO...

Time to get more input, we haven't had some flaming in a while...
 
>  At linux console (at least) the cursor is blinking if the textinput is
> 'entered' and hidden if 'not yet'. Also, by using cursor keys (left,right) and
> Ins,Del the cursor is moving in text entry (as it should) if the textinput was
> 'entered'. But statusline is that same if 'entered' and 'not entered' (its
> content is as in non-patched lynx). May be this should be fixed.

Yes, some of the statusline messages are not much appropriate for a
non-activated current field ("arrows or tab to move off." and similar
isn't necessary).

>  Also, when textarea (textinput with multiply lines) is encountered, user has
> to activate each line of it separately (seems not too bad).

Could be changed later.  WOuld probably a Good Thing but not straightforward.

> > > 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.
> > :)
> 
>  I had another alternative - write highlighting routine for text entries
> (probably highlight() can be used for this) - but I prefered to to what I did.

To put my idea from another message in yet another way: we may already
have that, in the form of the highlight(ON) call.

> > >[...] 
> > >  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.
> 
>  Even for this case two variables should be used - one for globaly setting
>  whether non-sticky-inputs are supported, 

Yes, that's a given

> and another - whether current
>  textinput was activated 

In my simple thinking, this wouldn't be needed - once control is passed
to change_form_link (or form_getstr), the field is activated; and once
control has returned to mainloop, the field is deactivated.

> (and 3rd flag is required to do what 'textarea_drawn'
> does if we wish highlighted and unhighlighted textinputs to look different).

That too might automatically be taken care of by the usual logic for
highlight(ON), assuming we just stop preventing that call for text input
fields.

But I'm not claiming that this would work for all cases (or at all), I
probably have overlooked something.

  Klaus