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

[Vlad Harchev]

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

 And we should think of the corresponding name for commandline option (IMO it
shouldn't be that long).
 
>[...] 
> 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.

 Yes, you are correct.
 
> 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?)

 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.
 Also, when textarea (textinput with multiply lines) is encountered, user has
to activate each line of it separately (seems not too bad).
 
> > 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.

> >[...] 
> >  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, and another - whether current
 textinput was activated (and 3rd flag is required to do what 'textarea_drawn'
does if we wish highlighted and unhighlighted textinputs to look different).

>[...] 

 Best regards,
  -Vlad