Re: lynx-dev "sticky" things

[Vlad Harchev]

On Sat, 16 Oct 1999, Klaus Weide wrote:

> On Fri, 15 Oct 1999, Vlad Harchev wrote:
> 
> Well thank you for the patch.
> 
> > My habbit to enclose all changes in cpp conditionals could help you to 
> > search
> > the LYReadCFG.c and find out that there are 2 settings regarding this. You
> > could also have searched 'textfield_stop_at_left_edge' in sources and 
> > discover
> > its default value... And I finally wonder, why the name 
> > 'textfield_stop_at_left_edge' didn't inspired you about its destiny :)
> 
> It is not as descriptive as you think.  Just 'stop' doesn't say much.
> Does it mean 'stop_at_left_edge_and_ignore_key_completely'?  Or
> 'stop_at_left_edge_and_ask_the_user'?  Or stop_and_something_else?

 Sorry for such bad name. English is not my native language, and I know it
very bad (as all noted) - at least I don't know a lot of russian->english
mappings. Please check the variable names and configuration
settings' names I introduce in posted patches and provide better alternatives.
This won't hurt me. All lynx-devers should remember this (Tom especially).
 
>[...] 
> I did.  There was *no* message from any lynx-dever, in that thread at least,
> that "preferred the new behaviour"!  You are twisting the truth.

 I checked it. There is no positive comments in that thread. But in the
announcement message I wrote that several people asked for that. I don't think
that I was twisting the truth that time (Aug 14). At least, this is not
intentional.

> Philip Webb: "i don't want this change, let alone need it"

 This was said about making this change unconditional (ie dropping old
behaviour).

> The rest of the thread was mostly about how to turn it off or on, and
> how to name the thing, nobody said they wanted the new behavior.
> Maybe in some other threads somebody said something to that effect.
> But as far as I can see from the archive following your pointer, you
> simply declared the old way "annoying behaviour" and that was it.
> 
> Ok, I dare you to find *one* user (other than you) who finds the
> current STICKY_FIELDS:FALSE is an improvement over STICKY_FIELDS:TRUE
> and would actually use it.

 IMO it's useful for former Windows users (that don't know traditional unix
keybindings). If the keyboard repeat rate is slow, and user whishes to get to
the begining of the text input, the user will press arrow-left for some time,
that (depending on the keyboard rate) will get him to the main page (in worst
case) if the textinput was not edited. I can imagine how badly the user will
characterise lynx - I did this before the sticky* patches too. The fact that
few or none lynx-devers said they wished that feature can mean that there are
no unix-newbies here. IMO, as long as this feature can be turned off (and is
by default now), it can be in the code (it's only 3 line-patch).

> Let's review what this is about.  In all cases, assume a text input
> form field field is current, and cursor is in the first position
> within.  (and no sticky-of-the-first-kind in effect).
> 
> User presses Left Arrow.
> 
> Old: two possibilities:
>     a) Lynx does PREV_DOC
>     b) Lynx asks user "Do you want to go back to the previous document?"
>        and then acts according to answer.
> Which of a) or b) applies depends on whether the text in the input
> field has been edited "just now".
> 
> "Vlad's new behavior which he calls STICKY_FIELDS:FALSE":
>     c) Lynx ignores the Left Arrow key without any feedback.
> Always. (if it's enabled.)  (If I misunderstand, correct me.)

 You understand it correctly.

> A reasonable modification of the old behavior would have been to change
> it so that (optionally?) always b) applies.  Or so that b) applies in
> more situations (effectively changing the definition of "just now
> edited".  In other words, make the prompt appear more often, give
> the user a chance to decide each time the situation comes up.

  Yes, I consider always asking to be better behaviour than my patch provided
 (I don't prefer to change the definition of "just now edited"). I'll
attach a patch to this message . But now I think that to be fully constistent,
we should have something like setting

CONFIRM_LEAVE_DOC_IN_TEXTFIELD:NEVER|IFCHANGED|ALWAYS

 If value is NEVER, PERV_DOC_QUERY will be never asked,
             IFCHANGED - old behaviour
             ALWAYS - ask always.
 For competness, IFFORMCHANGED should be added as accepted setting too.
 What do you think? 
 
> It would be so trivial to just always issue the prompt.  The code
> for the prompt is already there.  But no, instead we got something
> more useless AND more complex.  A "patch that will *prevent* returning
> to the previous[...]" (my emphasis), rather than a patch that would
> help avoiding *accidentally* returning.

 IMO it's not so useless and it's not complex. It doesn't prevent returning
completely, it "prevents from returning to the previous document from the text
field by pressing arrow-left" - there is a difference.

> I just can't imagine that anyone wants Left-Arrow-does-nothing-whatsoever
> behavior.  I can't imagine why Vlad would want that either, but I guess
> I have to take that as a given.

  As I remember, I left accidently a dozen of pages just because I pressed
excessive 'Arrow-Left' (usually there are more than one excessive keypress, so
sometimes I return to the main page - and this really annoys me). I can add
that I don't fill web forms very often, if I did, the number of accidentally
left pages could have increased signtifically.

> (Of course, if the purpose of all this is to avoid accidental leaving
> of all pages that have any modified form fields, then doing something
> only on text input fields is not enough.  You'd have to check for
> modified form fields within the whole document at any PREV_DOC,
> probably in mainloop.)

 No, this was not mentioned as a mean to prevent returning from filled forms.
 The problems it's designed to solve are described above by me.

> Now, about naming the options in lynx.cfg:  now we have
> 
>   # STICKY_INPUTS - Input
>   # This option controls whether all text inputs are sticky.  If input is not
>   # sticky, then it won't intercept any keyboard input until user activates it
>   # (as usual link).  Making inputs non-sticky can be desired for users who
>   # actively use alphanumeric keys for navigation (as ' ', 'b', INS, DEL, 
> etc).
>   # Default is TRUE - i.e., all inputs are sticky, this is old lynx behavior.
>   #
>   #STICKY_INPUTS:TRUE
> 
>   # STICKY_FIELDS - Input
>   # This option controls whether pressing an extra key-left in a text field 
> will
>   # activate the previous document.
>   #
>   #STICKY_FIELDS:TRUE
> 
> The choice of option names make no sense whatsoever.  Both are about
> _text input fields_.  Calling one STICKY_"INPUTS" and the other
> STICKY_"FIELDS" is without any logic I can discover.  It looks
> completely arbitrary, you could just as well exchange them.

  If you read the thread carefully, I released the patch with unconditional
behaviour. Then I asked Tom to invent the name for setting and add a line in 
LYReadCFG.c to make it configurable. I don't find the name of the setting
very descriptive, but the description is good (I would have written 
exactly the same), thou' it should be reversed (will -> won't) to be correct.

>[terminology and options' names analysis skipped]

> So I ask you, unless other folks say that things are fine as they are, to
>   Please get rid of the "sticky" terminology.  Find something better.
>   Please either get rid of your sticky-of-the-2nd-kind option
>   altogether or make it do something more useful.

  As for terminology, it doesn't matter for me what words to use (I can use 
"trapping" or anything else - provided the definition is publically available
and is clear). I don't know English good to invent synonims/terms - so I leave
this task to lynx-devers and you in particluar. It doesn't matter for that the
names of configration settings, C variables should be changed - Klaus, do it
if you find this useful.

  Here is a patch (mostly to point my idea on how this should be done):

diff -ru old/src/LYForms.c fixed/src/LYForms.c
--- old/src/LYForms.c   Thu Oct 14 16:20:35 1999
+++ fixed/src/LYForms.c Sat Oct 16 11:14:04 1999
@@ -640,17 +640,14 @@
                if (MyEdit.pos == 0 && repeat == -1) {
                    int c = YES;    /* Go back immediately if no changes */
 #ifndef NO_NONSTICKY_INPUTS
-                   if (sticky_inputs
-                    && !textfield_stop_at_left_edge)
+                   if (textfield_stop_at_left_edge) {
+                       c = HTConfirmDefault(PREV_DOC_QUERY, NO);               
    
+                   } else
 #endif
                    if (strcmp(MyEdit.buffer, value)) {
                        c = HTConfirmDefault(PREV_DOC_QUERY, NO);
                    }
                    if (c == YES) {
-#ifndef NO_NONSTICKY_INPUTS
-                       if (textfield_stop_at_left_edge)
-                           goto again;
-#endif
                        return(ch);
                    } else {
                        if (form->disabled == YES)


  The behaviour the patch introduces:
if textfield_stop_at_left_edge is true (controlled via STICKY_FIELDS), then 
for each extra keypress lynx will ask PREV_DOC_QUERY text 
('Do you want to go back to the previous document?' in English) with default
answer NO. The fact that default answer is NO means that any key other than
corresponding to YES will mean NO (arrow-left will mean NO too).

 While writing the patch, I found an incorrectness of the name INPUT_FIELDS
and it's description. The value TRUE of INPUT_FIELDS turns on new behaviour,
while it shouldn't according to the description, and viceversa. 

  But I feel that you'll welcome the more general 
CONFIRM_LEAVE_DOC_IN_TEXTFIELD described in the middle of the message, so that
the textfield_stop_at_left_edge will be removed, and some variable like 
confirm_leave_doc_in_textfield will be introduced. 
 

>   Klaus
> 

 Best regards,
  -Vlad