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

[Vlad Harchev]

On Thu, 29 Jul 1999, Klaus Weide wrote:

> An alternative do-it-yourself patch for Vlad's new feature.
> 
> This is meant to demonstrate what I was talking about -
> (1) a simpler approach and (2) a different way of displaying
> a text imput field that is 'current' but not 'activated'.
> 
> Use either as-is (then there will be no way to turn the 'modal
> behavior' OFF).  Or - this is where the DIY comes in if you wish -
> combine with some option-handling code, possibly from Vlad's code,
> and replace the two 'FALSE' with <a variable which is FALSE(!) if
> the new modular behavior is desired, and which is TRUE for the
> regular auto-entering behavior>.  But for a quick demonstration
> just applying the patch to LYMainLoop.c is all that's needed
> (no recompilation of other source files necessary).

 Yes, it partially works (it doesn't work for textareas). 'Unentered' but
selected textinputs have color of current link. Activating them makes them
colored as textinputs in old lynxes (with color of plain text). 

> Various things are wrong or not done here, at least:
>  - different statusline text missing
>  - ENTER after editing (non-submitting) input fields never moves
>    to next field or link.  (Does it with Vlad's code?)

     Yes, it works with my patch, and doesn't work at all with yours.

>  - ENTER on last TEXTAREA line does not grow the textarea at all

      Seems this the only problem with your patch - autogrow is impossible.

>  - interaction with mouse not tested at all (as for Vlad's code)
> 
> 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.
> 
> One small "feature" that comes for free (maybe unnoticed by many,
> possibly very useful to some, so worth pointing out), the -show_cursor
> is honored and has the expected effect.
> 
> Could someone please compare this to Vlad's code, and comment on the
> 'visual' differences (and overlook the things mentioned above as
> missing).   I admit I still haven't tried his code, but I think
> I understand the main differences from his code and explanations.

 The only thing I don't understand with your patch: how activation of
textinput happens (what code is responsible for this)?
 Also, IMO solution you propose is not complete (we can consider it as another
was of drawing non-activated textinputs). 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.

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

 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.


>[...] 

 Best regards,
  -Vlad