Re: lynx-dev "sticky" things

[Klaus Weide]

I find a Y/N question less annoying than a statusline-with-wait, one
can answer it immediately instead of waiting 1 or 2 seconds.  (Assuming
messsage pauses aren't completely turned off - I don't set them off.)

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

Lynx doesn't keep a "forward" history internally, so the question of which
key to use for it doesn't come up...  OTOH the fact that the Right Arrow
key is already taken is probably one reason why nobody implemented keeping
a forward history...

But you can use V (VLINKS) in that situation, for the most part.


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

Well, I think the explicit prompt makes the most sense to beginning users,
and should be obvious even if they come from the windows world.  But
we are both speculating...

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

But lynx is really quite different form the GUI world.  With mouseclick-
browsers one doesn't need the Left Arrow key for navigation between
documents, but in lynx it is *the* way for going to the previous document.
So it has a double function, you don't have that ambiguity in GUI browsers.

(If one uses Lynx as a mouseclickbrowser, say on windows, always using
the mouse to travel between documents, then that would be different.
I don't know whether it's even possible in a reasonable way.  But I'd
say that's not the use we are usually thinking of.  At least I assume
the a lynx user needs to know how Left Arrow and Right Arrow work
between documents.)

Larry has reminded us that ^V is a "bad key", at least for some users.
I agree that it shouldn't be featured as *the* way to do some things
like elementary navigation; there should at least be another way, too.

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

Is that what you want, or are you just speculating "how does lynx do that"? :)

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

I don't kow how you mean that question; it should be obvious that if Q had
the QUIT (or ABORT) meaning in a text imput field then you couldn't enter
a capital letter 'Q' in the field, so you must mean something else.

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

But there is a good reason for its special treatment.  The comment in the
relevant part of the source says
            /*
             *  Left arrrow in column 0 deserves special treatment here,
             *  else you can get trapped in a form without submit button!
             */
It seems to me this behavior was specifically introduced to solve a
real problem.  You assume that you alwas can move to a previous or
following link or field which isn't a text input field, but what
if there aren't any?

That was before ^V (with its escape-from-line-editing meaning) came into
existence.  Now you can always escape from such a trap with ^V *if*
the key works as expected for you and if you have learned about it.
It's still good to have another way.

(You need ^V for QUIT from within a text input field.  But *needing*
to do that should be extremely rare.  If you can get to a previous
document, that's usually one from which you can QUIT normally, or
you have to go several times back.  If your start document is already
trapping one, well "don't do that" (or use ^C...).)

Anyway, it seems Vlad is going to do the Y/N prompt thing (just making
configuarable when that occurs vs. automatic PREV_DOC).  I am happy
with that (except for the name).  If you want a different variant
bad enough, try to convince him...

   Klaus