Re: lynx-dev "sticky" things

[mattack]

On Sat, 16 Oct 1999, Klaus Weide wrote:
>On Sat, 16 Oct 1999 address@hidden wrote:
>> On Sat, 16 Oct 1999, Klaus Weide wrote:
>> >"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...)

Well, it does show I usually ignore the statusline.  I'm trying to put myself
in the mindset of the naive user, without dumbing down everything for the
sophisticated user.

I guess I do mean #3 overall, but since there's already code that knows when
you hit backarrow when the cursor is in the first position, #2 is reasonable
in addition.  The existing message tells people how to exit the field 
normally.  The hypothetical new message would tell people how to really go
back when they're editing the input field, but wouldn't 
(1) lose data  or
(2) break the user's concentration as much as a Y/N question would

Heck, this is showing my own lack of knowledge about Lynx..  In the past, 
I have tried to figure out how to get back where I was when I accidentally
left-arrowed (not just from edit fields, maybe I was just leaning on the
key), and maybe I missed the obvious, but how can I do the equivalent 
of the "forward" key in a GUI browser?   Right-arrow is IMHO the logical 
choice but it does the same thing as return.

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

But it gets in the way, since it makes them answer a question.  I guess I 
am trying to make it a 'text editing mode' that the user enters, but one
that the user enters implicitly by moving the cursor to that link, rather than
expressly selecting the link after moving the cursor to it.  So I think that
it should be hard to do anything except uparrow, downarrow, or return when
you're in an input field.  "Hard" meaning you have to give the ^V command
key.  (Personally, I would just move off the link THEN give the command.)
I would configure my own copy this way if I were building recent builds.

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

Yeah, you're right, as I explained above.  I don't consider it "less obvious",
I consider it less intrusive.  I'm having modal behavior, but modal behavior
that does not seem modal unless you want to do unusual things.

>> 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, I already get into this situation sometimes when I want to quit Lynx
(i.e. the Q going into the edit field).  I personally don't consider it
that big of a deal.  It looks like there are viable arguments for both
sides of the issue, so leaving it in seems reasonable.

I still think it's possible to argue well that ignoring left arrow at the
beginning of an input field makes the most sense for beginning users.  As much 
as I try not to use it as an example, this is how it works in the GUI world -
left arrow in an edit field does nothing, but you can still tab to other 
fields to type in.  My "modal but not noticable" discussion above is really
just emulating what I consider reasonable user-focused behavior (do what I mean
not what I say).  lvirden has already said he doesn't think default behavior
should be changed.

Though these are both ridiculous examples, they popped up in my thinking
about this whole issue:
* When you have a fixed-length edit field, why doesn't right-arrow at the 
very end take you to the next link?
* When you're typing in an edit field, why doesn't it ask you "Do you really
want to quit?" when you type Q even in an edit field?

Seems to me the existing leftarrow at beginning special casing is really the
very strange special-cased behavior in the whole situation, and is living on
just because it's always been that way.