lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev nothing changes/no way to save changes on O)ption page


From: Klaus Weide
Subject: Re: lynx-dev nothing changes/no way to save changes on O)ption page
Date: Thu, 28 Oct 1999 15:41:27 -0500 (CDT)

On Thu, 28 Oct 1999, Henry Nelson wrote:

> > Let me guess: you are using
> > 
> >   --disable-menu-options  disable old-style option menu
> > 
> > It's not your fault lynx behaves wrong with that...
> 
> Good; I thought so, but didn't have time to debug it.  (Easier to hand
> edit .lynxrc for a quick fix.)
> 
> > Could someone please fix the illogical definition of LYUseFormsOptions.
> 
> Not just fix, could things be simplified greatly?  Right now there is an
> attempt to allow three compile-time options: old-menu only, forms-menu only,
> or both.  On top of that, there is the FORMS_OPTIONS toggle in lynx.cfg,
> which is applicable if the third, "both," compile-time option was selected.
> 
> I know I will get bashed for saying this, but I will anyway :).  

No bashing, but I disagree.  I don't find what you describe in your
previous paragraph is overly complicated.  It makes sense when spelled
out nicely (as you did :)).

It is not a strong disagreement - if lots of folks agree with you I'll
be quiet.  I admit it is mostly because I feel that folloing through
with your proposal would inconvenience *me*.  (Still I think I am not
the only one.)

> This kind
> of "fraternizing" all schools of thought is going too far.  All that is
> necessary is one, either-or, configure option/compile switch.  Because forms
> handling has been MUCH improved since earlier Lynxes, I sincerely believe
> the forms method is easier for newbies.  For this reason I recommend that
> the default be forms options enabled.

I still suspect it has some problems lurking somewhere that the
old-options implementation doesn't have.

>  Still, the old-options IS faster,
> and IMO is also preferred for public-access (anonymous) use.  In most
> cases, old-options users will tend to be the more experienced, 

Your characterization of forms-options vs. old-options users sounds
more or less right, in a broad-brush statistical way.  But like all
statements of this sort, it leaves some out.

> and it will
> not be difficult for them to add a "--disable-" or "--without-" option.

Not all old-options users compile lynx themselves (nor should they have to).

> So, although it may go against what I said a year or so ago when forms
> options was first introduced (and still experimental, IMO), let's do away
> entirely with --(en|dis)able-menu-options and the toggle in lynx.cfg, and
> keep only the option to, by default, enable forms-options AND disable menu-
> options, OR disable forms-options AND enable menu-options.
> 
> The only disadvantage is that a *handful* of people will be stuck with
> forms when they want the _old_, _no-longer-supported_ menu.

I disagree that it's only a *handful*.

I also disagree that it is the *only* disadvantage.  Some things are
much more convenient/ quicker with the old-style options; but future
options are unlikely to be added to it and will only be available in
the forms-options version.

> I sympathize,
> but these people still have some options like compiling their own or
> going to another ISP.

Sure they have, but why should they be forced to face such an
inconvenience?  Basically, you haven't shown enough (or any) benefits
to the many that would balance the inconvenience to the some.

   Klaus


reply via email to

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