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

[Klaus Weide]

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

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

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

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)

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

   Klaus