Re: lynx-dev "sticky" things

[Klaus Weide]

On Sat, 16 Oct 1999 address@hidden wrote:
> On Sat, 16 Oct 1999, Klaus Weide wrote:
> >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.)
> 
> Except for the "without any feedback" part, I can say I'd prefer this method.
> I would want a status line message saying something like:
> To go back from within a text field, type ^V-leftarrow, or exit the field and
> then type left-arrow.

To clarify, do you mean with "status line message"
1) a dialog (Y/N)  [well apparently not]
2) A message with a certain duration (you can turn off the 'sleep' of course)
3) Just a different choice of words for the 'static' line that is shown
   now (you want it to mention ^V-leftarrow)
4) something else

for 3), the statusline already should say something like what you want
(but without mentioning ^V): "Use UP or DOWN arrows or tab to move off".  
(If you were not aware of that, then maybe that shows that an informative
statusline message alone isn't much use...)

> Heck, I think this should be the default.  I surmise new users are confused
> as hell by accidentally left-arrowing their way back many pages when they're
> just trying to edit some text.  

Then 1) is the surest way to prevent that.  Which would normally happen,
with the original code, if the text in the field really has been edited.

> I don't think they want (and I know I don't
> want) the equivalent of "modal dialogs" coming up and requiring me to answer.
> The status line message gives useful info to those who need it, and those who
> don't probably already have -nopause on.

If it's only an informative message, it doesn't prevent accidentally
overshooting unless Left-Arrow is blocked (ignored).  But if Left-Arrow
is blocked, you effectively have modal behavior, only a bit less obvious,
IMO.

> Having to type ^V-leftarrow is vaguely equivalent to having to type command-
> leftarrow in a GUI browser (or alt-leftarrow or whatever IBM ones use). You
> make the common thing easy, and the less common thing slightly more tedious.
> 
> >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.
> 
> So are you saying ^V-leftarrow won't work in this situation?

It would (and does).

> >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.
> 
> Well, if I ever get a version of Lynx compiled with it in, I'll turn it on.

But keep in mind that this applies to *all* text input fields, not just
those you have any interest in, not just those you have modified.  You
page to the last screenful of some Web page, it happens to have a text
input field near the top.  Normally you'd press Left Arrow to go back
and not even notice there was an input field.  (If you're in human
"browsing mode", not in "I want to fill in forms" mode.)  Now (with the
sticky-of-the-2nd-kind setting) the input field requires taking notice
(why didn't Left do anything?) and then taking action (probably ^V).

Well that's my experience.  I am just speculating that you *might* change
your mind, too.

Maybe I think differently because I'm rearely in "want to fill in forms"
mode.  I expect Left Arrow to do the normal Left Arrow thing, unless
there's a special reason.

> >  # 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).
> 
> Uggh, that's just the way w3m does it.  Yuuuck.
> 
> >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
> 
> It's not really sticky, it's modal.  But I can understand from context why
> it's called sticky.

We all have the context, at least from getting used to seeing the term
on the list now.  But a term that would be more obvious without "context"
would be better.

> >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.
> 
> No, the don't-go-back and also don't-prompt-me option is useful (with the
> addition of a helpful message as described above).

Ok, I do take note that you find it useful (but in modified form, and you
haven't experienced it).

   Klaus