Re: lynx-dev Re: syntax change

[Laura Eaves]

> Date: Mon, 1 Mar 1999 15:16:48 -0800
> From: Kim DeVaughn <address@hidden>
>...
> | 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.
>...
> 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").

By "hidden links" I mean anchors with HREFs but no highlightable text.
I'm not talking about form fields of type "hidden".
Offhand I don't remember how to check for hidden-ness.
It's been a while since I looked at this code.

> | How about the following: treat 123 like 123g for all links
> | except invisible links...

I'm still open for feedback on this one... (Guess I haven't learned...:)
Reversing the meaning of 123 and 123g would be too confusing now that
people are used to using 123g.
Also, I hesitate to eliminate the g suffix since it makes
the syntax for 123[g|p][+|-] more uniform.
There are lots of picky alternatives to this.
I think I'd rather eat dinner now than hash through them all again...:)

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

What do you think the interface should be?  What option(s) on the options menu
&&/|| lynx.cfg &&/|| .lynxrc &&/|| command line? and what should it/they
specify?

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

More after dinner... :)
--le