lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev Re: lynx.cfg bloat (was various fixes)


From: Heather
Subject: Re: lynx-dev Re: lynx.cfg bloat (was various fixes)
Date: Thu, 19 Aug 1999 14:57:03 -0700 (PDT)

> On Thu, 19 Aug 1999, Philip Webb wrote:
> 
> > does anyone other than us four have thoughts on this subject?
> 
> Yes. The explanation of configuration options needs to stay with the
> file where options are set. Otherwise changing the configuration
> becomes entirely too difficult.
>                            Doug

I agree; in fact, I'd say if the complaint is that lynx.cfg comments
are confusing, those comments should be improved, which means they
might need to be expanded.  (So much for mr. "Reduce bloat")  On the 
other hand I personally sometimes "strip" them not by truly stripping
them completely, but by reducing them.  I do drop some info, like all
those supported character sets... I keep a copy of the original elsewhere.
If someone wants me to provide the "reduced" edition, I'm willing to,
so it can be posted for user convenience.  

However, I wouldn't want my reductions to be the normal shipped lynx.cfg.
I personally suspect that although we have several documentation files, 
some users may only get the permissions to access and use the lynx.cfg.  
(Though this could lead them to the websites where much of the rest also 
lives.)  So it's critical as a piece of documentation, as well as the 
home of however so many options we've grown over time.  And I heartily
agree that that documentation should NOT be seperated from the options
themselves, because that's really the only way they make sense.

Sorting them differently is possible though.

As for changing options, or the complaint about too many options total:
I can see the possible beauty of multi-state toggles, but they seem
like re-implementation of already working features, which itself seems 
like an easy way to spend programmer time without actually seeing 
improvement for most users.  Plus the possibility of introducing bugs
where we've made such efforts to scrub them, so I don't see a real gain.
Sorry to say it, but the world has gotten more complex, and some admins
want to control them down to fairly fine grained details.  This is one
aspect in which lynx is far ahead of the big boys with their GUI gadgets;
don't make us throw out one of our finer features.

renaming them is possible, but we would want to come up with a standard
to stick to for a long long time following, because we would be breaking
people's ability to use their existing lynx.cfg's.  ouch.  A script to
translate old to new would be a good idea if we continue that route.

There you have it, the woodwork's opinion. :)

* Heather

reply via email to

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