Re: lynx-dev "sticky" things

[Klaus Weide]

On Sat, 16 Oct 1999, Vlad Harchev wrote:
> On Sat, 16 Oct 1999, Klaus Weide wrote:
> > On Fri, 15 Oct 1999, Vlad Harchev wrote:
> > > 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. 

It's not a "bad name", as variable names go.  I was responding to your
implication that it should be obvious from the name what it all means.

>  English is not my native language, and I know it
(nor mine; I'm sure the "natives" notice.)

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

> >[...] 
> > Philip Webb: "i don't want this change, let alone need it"
> 
>  This was said about making this change unconditional (ie dropping old
> behaviour).

I didn't read it that way, but ummh okay.

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

I don't object to a configurable option for this in general.  If you got that
impression you got me wrong.  It is the "gives no feedback or choice" part
of the previous patch I object to, combined with that it was the default,
combined with hard-to-understand logic and the ignoring of the already
existing prompt possibility...

>   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? 

I think it is fine.  It is what I would have expected your patch to do
from the beginning, and I was confused because it was doing something
different. :)

But it seems mattack wants something different now...

I suggest to change some details:

> CONFIRM_TEXTFIELD_PREV_DOC:NEVER|IFEDITED|ALWAYS
>
>  If value is NEVER, PREV_DOC_QUERY will be never asked,
>            IFEDITED - old behaviour
>              ALWAYS - ask always.

PREV_DOC instead of LEAVE_DOC - well, it's already the name of the key
                                action
no _IN_ - to make it a bit shorter (but if you disagree, fine)
no IFFORMCHANGED - that would seem to indicate that we check whether
                   the form as a whole (any field) changed.
IFEDITED (or IF_EDITED?) - maybe.  to not give the impression that
                           a different kind of change has something to
                           do with it?  Or leave as IF(_)CHANGED.

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

It was your subject line. (but maybe it was snipped...)
Yes, in no case is anything completely prevented.

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

Ok, so IFFORMCHANGED shouldn't be used (or be "reserved", if anyone ever
wants to do something like the above).

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

Will -> won't doesn't make it any more (or less) correct, in my understanding
of English (which might be wrong).  It doesn't say which of TRUE/FALSE has
one effect and whcih the other, either way.  If you want it to say that
(and I think you should), it should be spelled out.  As in many of the
good old options, "If XX is set TRUE, ...".

> >[terminology and options' names analysis skipped]
>   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.

I really want to get rid of "sticky", problem is I don't have a really
good different name.  Some were proposed
 <http://www.flora.org/lynx-dev/html/month0799/msg00771.html>
(maybe more in other messages).  (That's for sticky-the-1st, s-the-2nd
is going to get renamed anyway it seems.)

Below you eliminated the 'goto again' branch.  That was another source
of confusion: was that meant to act differently from falling through
to 'default:' ?

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

[ leaving only the new lines in: ]

> @@ -640,17 +640,14 @@
>               if (MyEdit.pos == 0 && repeat == -1) {
>                   int c = YES;    /* Go back immediately if no changes */
>  #ifndef NO_NONSTICKY_INPUTS
> +                 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) {
>                       return(ch);
>                   } else {
>                       if (form->disabled == YES)

... and then we can get rid of the NO_NONSTICKY_INPUTS symbol completely...

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

Yes, just like before *when* it issued the prompt.

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

YM STICKY_FIELDS(?)

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

Yes, please. :)

Except for mattack...

    Klaus