[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev Re: syntax change
From: |
Laura Eaves |
Subject: |
Re: lynx-dev Re: syntax change |
Date: |
Mon, 1 Mar 1999 19:10:36 -0500 (EST) |
> 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
- Re: lynx-dev Re: syntax change, Laura Eaves, 1999/03/01
- Re: lynx-dev Re: syntax change, dickey, 1999/03/01
- Re: lynx-dev Re: syntax change, Laura Eaves, 1999/03/01
- Re: lynx-dev Re: syntax change,
Laura Eaves <=
- lynx-dev Re: syntax change, Kim DeVaughn, 1999/03/01
- Re: lynx-dev Re: syntax change, Philip Webb, 1999/03/02
- Re: lynx-dev syntax change - f not g, Klaus Weide, 1999/03/02
- lynx-dev Re: syntax change - f not g, Kim DeVaughn, 1999/03/02
- Re: lynx-dev syntax change - f not g, Philip Webb, 1999/03/02
- Re: lynx-dev syntax change - f not g, Klaus Weide, 1999/03/02
- Re: lynx-dev syntax change - hidden links digression, Klaus Weide, 1999/03/02
- lynx-dev NNN <something-or-nothing> (was: syntax change), Klaus Weide, 1999/03/02
- lynx-dev Re: NNN <something-or-nothing> (was: syntax change), Kim DeVaughn, 1999/03/02
- Re: lynx-dev Re: NNN <something-or-nothing>, Philip Webb, 1999/03/02