lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

lynx-dev Re: syntax change


From: Kim DeVaughn
Subject: lynx-dev Re: syntax change
Date: Mon, 1 Mar 1999 15:16:48 -0800

On Mon, Mar 01, 1999, Laura Eaves (address@hidden) said:
|
| If hte target of
| 123[+|-] is a link, would following the link unexpectedly have any ill
| effects?

Nothing I can think of offhandedly (aside from the user being annoyed
with herself for using the wrong offset, or choosing the relative form
of addressing).  Even that possibility seems rather minimal, since an
*extra* keystroke is required to enter the relative form.


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

Heh.  Teach you to ask for feedback ... :-) ...!


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

Too bad it wasn't o(ption)alized back then.


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

Errr ... perhaps I am misunderstanding what you mean, but whilst I was
implementing all the TEXTAREA editing stuff, I certainly came across a
few anchors that were marked "hidden", but also had text "in" them (if
by "in" you mean "had a matching HTLine that was other than null").


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

Well ... you think it's "backwards", I think it's "backwards", and I do
believe that I've seen comments from others on the list that point to
their thinking that it's "backwards", so yes, I guess I do think that
an o(ption) is desirable.  Not required, but desirable.  Why should the
users of today's lynx be *forced* to live with a paradigm from the past,
for no reason other than "backward compatibility"?  Especially when there
is a more "natural" paradigm available.

BTW, I'm not suggesting a ./configure option, but rather a realtime, user
configurable o(ption) screen option.

Yes ... there are alot of options already.  Seems that that is one of the
hallmarks of "flexibility" ... especially in the "user interface" area.

/kim

reply via email to

[Prev in Thread] Current Thread [Next in Thread]