lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev lynx.cfg bloat


From: Klaus Weide
Subject: Re: lynx-dev lynx.cfg bloat
Date: Tue, 24 Aug 1999 09:35:33 -0500 (CDT)

On Mon, 23 Aug 1999, Henry Nelson wrote:

> > preferable over any hide-the-comments-somewhere-else approach.
> 
> Just want to be sure I am not being misunderstood.  I am not, and
> have never been, a proponent of separating comments from the actual
> settings.  I think the present lynx.cfg actually is a reasonably
> efficient way to configure Lynx.  [ ... ]

> > Actually that example goes in the opposite direction of what you want
> > as policy (to paraphrase, I hope correctly, "make similar things
> > suboptions of one option").  If they are similar enough to be explained
> > together, they should probably be "something:PRINTER:..." and
> > "something:DOWNLOADER:..."...
> 
> This is my view.  (Although, in this particular case where suboptions
> can be very long strings and where there can be an indefinite number of
> them, it might make more sense to keep it the way it is.)

I think they should stay as they are, in this specific case for sure.

> > A simple patch to send.  (I agree FORCE_SSL_COOKIES_SECURE should be
> > moved, I don't see any reason for the current placement.)
> 
> Not really a "simple" patch.  It is hardly worth shuffling the order
> of lynx.cfg settings around if that is all that is done, IMO.  If I were
> to do something, it would be to change that to COOKIES:FORCE_SSL_SECURE,

Well, if the placement is obviously wrong, it is worth changing it.
That's hardly a lot of shuffling in this case.

> > But this can happen whether comments are in a different place or not,
> > whether the .cfg file is split or not, right?
> 
> [So I was being misunderstood?]

No, I didn't think you were an advocate for splitting...  I don't know
what exactly I was thinking when I wrote that.  Probably that no amount
of changing mechanisms or introducing policies can guarantee that options
end up being in the most logical place.  (especially when historically
they were introduced at different times)


   Klaus


reply via email to

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