Re: lynx-dev alternative DIY patch for non-auto-input-field-entering

[Vlad Harchev]

On Thu, 29 Jul 1999, Klaus Weide wrote:

> On Wed, 28 Jul 1999, Vlad Harchev wrote:
> > On Thu, 29 Jul 1999, Klaus Weide wrote:
> > 
> > > An alternative do-it-yourself patch for Vlad's new feature.
> > > 
> >  Yes, it partially works (it doesn't work for textareas). 
> 
> What do you mean with "it doesn't work for textareas", anything else
> than the differenced I explicitly mentioned?  There shouldn't be any
> difference whether an input field is part of a textarea or not.  (And
> I don't notice a difference in my testing, although I have tested only
> with those changes applied to approx. 2.8.3dev.3 code.)

 I tested your changes with 2.8.2dev10.

 Pressing ENTER won't work in textarea (seems I described that in my message)
- so autogrowing won't work, nor switching to next line of textarea with
ENTER (seems similar to what you "predicted").

> > 'Unentered' but
> > selected textinputs have color of current link. Activating them makes them
> > colored as textinputs in old lynxes (with color of plain text). 
> 
> That's the main point of the demonstration.  It should act the same
> way for input lines that are part of a TEXTAREA.
> 
> >  The only thing I don't understand with your patch: how activation of
> > textinput happens (what code is responsible for this)?
> 
> All field lineediting is done in the lower change_form_link call, after
> 'case LYK_ACTIVATE:'.  It has to be, since the first one is completely
> disabled.
> 
> Just disabling the first change_form_link seems to unearth the ancient
> 'modal' behavior, the logic for which has survived in a usable for all
> these years although it was basically unused.  Code archeology...
> 
> >  Also, IMO solution you propose is not complete (we can consider it as 
> > another
> > was of drawing non-activated textinputs).
> 
> I think I said as much. :)  (but I also think that making it 'complete'
> will overall require less changes in various places than your approach.)

 May be (but if extended textarea editing will be implemented, changes to 
highlight() are required in order to track down the moment of changing the
link). 
 Support for statusline changes will also require something...

> > If any extra logic is to be written
> > (like the one with textarea in my patch, or even support for statusline
> > messages) state variable should be added.
> 
> I can think of basically two ways to add code for missing behaviors:
> - Duplicate some of the logic surrounding the first change_form_link call
>   in the block surrounding the second change_form_link, iwht appropriate
>   modifications.  Maybe some of that should have been done for consistency
>   anyway.  No new state variables should be necessary.
> - Modify the condition on the block surrounding the first change_form_link
>   such that it isn't always skipped, or maybe the change_form_link itself
>   is skipped but some of the surrounding code isn't, based on some state
>   variable(s).
> 
> >  Another point of difference:
> >   user is able to see both 'head' and 'tail' of long textinput ('head' when
> > it's not-current, 'tail' when current, but not acivated) without activating
> > the textinput with my patch (while only 'head' without activating with
> > solution you suggest, and it's impossible to say, is there any text after
> > the piece of text shown in a given textinput without activating it).
> 
> Difference noted.  Avoiding distracting scrolling (unless and until
> "requested" by entering) can be a good thing (according to taste), but
> some "there's more than shown" indication should be added in some
> form.
> 
> But how does your code behave with input fields where MAXLENGTH is
> exceeded?  (At first I thought that's what you are talking about,
> given the terms "head" and "tail".)  These things are rare, but *when*
> they occur the messages can be *very* annoying with the current code
> if a number of fields are too long.  They should definitely be skipped
> in the 'modal' mode, this alone would be a good reason for having it
> (actually the best one I can see for me personally).

 I doesn't deal with them in present state (but since the 'redraw_only'
argument is added to change_form_link_ex, we can remove messages about
very long input text very easily).
 
> Try moving among a number of 
>   <INPUT name=x value="abcdefghijklmnopqrstuvwxyz" maxlength=20>
>   <INPUT name=y value="abcdefghijklmnopqrstuvwxyz" maxlength=20>
>   <INPUT name=z value="abcdefghijklmnopqrstuvwxyz" maxlength=20>
> (with messages not being suppressed)

 tested it (lynx warns about too long input when making that textinput
current, and warns when making textinput "active") with my patch, and warns
only when making textinput "active" with your patch.
 
> > > Those could be added/corrected in various ways; the result might look
> > > similar to Vlad's code in many respects, but with the important
> > > difference remaining that no argument is added to change_form_link for
> > > just-as-if-editing display, and no change to highlight() necessary.
> 
> >  As for change_form_link - the number of its arguments is not changed with 
> > my
> > patch - it just became a wrapper to change_form_link_ex.
> 
> Well, make that 'no argument is added to form_getstr for
> just-as-if-editing display, and no new variant of change_form_link is
> needed, and no change to highlight() necessary'.

 Of course, I don't consider my patch elegeant - this is actually a hack...
 You can continue working in the direction you proposed - sorry I don't have
time go in your direction.

>[...]

 Best regards,
  -Vlad