Re: lynx-dev Re: syntax change

[Laura Eaves]

> Date: Sun, 28 Feb 1999 16:31:26 -0800
> From: Kim DeVaughn <address@hidden>
>...
> On Sun, Feb 28, 1999, Laura Eaves (address@hidden) said:
> |
> | I've also been thinking 123+ and 123- without g or p should be
> | outlawed as the user is less sure of the destination link when
> | typing relative numbers.  Any thoughts?
>
> Yes.  I really dislike interfaces that attempt to protect me from
> myself, based on someone else's notion of what's good for me.
>
> Unless, of course, there are destructive consequences, such as
> causing the display to get trashed, or side-effects such as deleting
> files, etc.
>
> In this case, it's not harmful, so it shouldn't be disallowed based
> on the vague notion of a user being "less sure" of something.

Well the behavior of 123[+|-] (with no g or p) is different when the target
is a form field (including form submit buttons) than for a link.  In the case of
form fields, 123[+|-] acts just like 123g[+|-], therefore nothing will be
accidently changed if the user ends up on the wrong link.  If hte target of
123[+|-] is a link, would following the link unexpectedly have any ill effects?
See also below.

> | I could easily change the syntax again to 5g+, etc if people really want
> | it that way.  But I'll wait for replies first....
>
> I think your original syntax was just fine.
>
> OTOH, it should be easy enough to allow *either* 123+g or 123g+ to
> be valid, with only an additional line or three of code (just a bit
> of peeking ahead at the char following the initial "+" or "g", etc).
>
> *Requiring* a leading 0 however, is obtuse, IMO, though it too could
> probably be made optional (doing so would probably require more than
> a line or two of code, since 0 is recognized as a command in and of
> itself (F_LINK_NUM), even when link numbering is turned off).

It wouldn't require much to recognize either syntax, but I'm getting lazy after
changing it 3 times already...:)

> Finally (since you're fiddling with the interface anyway), *I* would
> really like to see a way to avoid having to enter the "g" at all, since
> most often, I want to move to a link, before activating it.
>
> For those few times when I actually *do* want to immediately follow the
> target link, adding (say) an "f" to the link number, wouldn't be a
> problem for me.

This was discussed way back when Klaus first implemented 123g.
As I remember, the meaning of 123 (with no g) was left unchanged for
backward compatibility.  Also there was a long discussion on how
"hidden" or invisible links should be handled.  (Note that hidden links
have no text inthe anchor, so they cannot be selected as the current link.)
Older versions of lynx treated these like visible, giving htem link numbers.
This meant that a user could follow invisible link 123 by
typing 123, even though the link could not be selected as the current
link.  So for hidden links, 123g would also fail.
Since hiddenlinks are sometimes intended by the page author and other times
accidental (say, the result of parser error recovery), I voted to
continue treating hidden links as before so as not to lose links that the user
would like to see.  Fote wanted to remove them.  Klaus compromised by
making it configurable.

Anyway, I agree the 123 and 123g syntax is backward.
You would think hte meanings would be reversed.
How about the following: treat 123 like 123g for all links
except invisible links...

> I suppose a configurable option for this is probably too much to ask for
> though (sigh).

IMO, lynx already has too many configure options, which seem to be
added every time a small change is made.
Does this require a config option?
--le