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:
> > 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.
  
 But only if we have INPUT word in the name (otherwise it can be redundant).
 
> >  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...

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

 I'll send a patch to add statusline messages.

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

 May be (but it's not indentical to what the patched lynx currently does - 
 it 'highlight' won't scroll to the end nor add braces).

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

 In this case we should interpret all lynx commands (like '.','h','l','g') in
 change_form_link - it's much more difficult.

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

 I think that it can be left as it's now (I mean the algoritm of
highlighting, number of variables, keyboard input passing) with my 
small patch applied (I'll send it in several minutes, it will add statusline
message).
 
>   Klaus
> 

 Best regards,
  -Vlad