lynx-dev "sticky" things

[Klaus Weide]

On Fri, 15 Oct 1999, Vlad Harchev wrote:

> On Fri, 15 Oct 1999, Klaus Weide wrote:
> > *All I want is the previous behavior back*.  That's how I aproached that
> > section of code.  I was even prepared to define some NO_ macro should
> > that be imposed now by you.  But I look at the code, and I can't even
> > figure out without a major study effort what I have to do or whether there
> > _is_ anything I can to to get the previous behavior back.  *I want to get
> > the PREV_DOC_QUERY prompt* if necessary, answer with Y or N, and then see
> > lynx react accordingly.
> 
>  OK. I didn't think you don't read diffs to lynx.cfg. Just set
> STICKY_FIELDS:TRUE in lynx.cfg and you'll get old behaviour. If other
> users/developers prefer old behaviour as default (IMO it's more logical to be
> backward compatible), replace line in LYMain.c:
> 
> PUBLIC BOOL textfield_stop_at_left_edge=TRUE;
> 
> with 
> 
> PUBLIC BOOL textfield_stop_at_left_edge=FALSE;
> 
>   to make old behaviour the default.

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?

And Lynx already _did_ already 'stop' (and prompt) without your changes.
That's why the HTConfirmDefault() call is there after all.

> > 
> > I'd like to see *one* person besides you who finds it useful that you
> > have taken away the flexibility of a prompt and replaced it by a
> > configuaration choice between fixed always-yes or always-no behavior.
> 
>  When that feature was added, there were a lot (2-3) messages from lynx-devers
> that told that they prefer that new behaviour. Search the archive for
> messages with "[PATCH 2.8.3.dev6] patch that will prevent returning to" in the
> subject.

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.

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

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.

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

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.

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.

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.

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

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.

Calling both options, which are completely different, "STICKY"_something
with INPUTS vs. FIELDS the only difference is perfectly confusing, to
say the least.

The description text also has multiple problems ans should be rewritten.
What does it mean that "text inputs are sticky"?  What is a text input
anyway?  You mean an input _field_.  Text input fields don't "intercept"
keyboard input when you type in them.  (And note that in that second
sentence you use "input" in a different sense.)  Maybe "accept".
I would not call going back to a previous document "activating" it.
And of course you completely omit mentioning the prompt in the old
behavior, giving the impression that with sticky-of-the-2nd-kind
Left Arrow would always go back to the previous document which is
just not true.

I objected to the "sticky" terminology when you first introduced it,
in the very first response to your "non-sticky of the 1st kind" patch:
<http://www.flora.org/lynx-dev/html/month0799/msg00769.html>.  It is
an awful name, I don't find it is a good description to call lynx's
normal behavior "sticky".  I suggested some other names, there was
some discussion.  You said you didn't care what it's called.  But you
haven't changed it, and then you went and added more "sticky" stuff.
It seems the word has stuck with you.  (See why it's bad?)

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.

  Klaus