Re: lynx-dev dev.18 patch: USE_PRETTYSRC, lynx.cfg

[Klaus Weide]

On Sun, 9 Jan 2000, Vlad Harchev wrote:
> On Sun, 9 Jan 2000, Klaus Weide wrote:
> > On Sun, 9 Jan 2000, Vlad Harchev wrote:
> > 
> > > PRETTYSRC.ATTRNAME_CASE:
> > 
> > Please noooooooo...
> 
>  Why?

I'll save more serious arguments for the (I hope unlikely) case that
anyone else but you thinks that it is is a good idea to do this.

Note that I say: to *do* this.  Not just to speculate "wouldn't it be nicer
if our syntax looked like this", but to actually proposed doing it.

>  Please don't be so emotional about FOO.BAR. Why do you hate it so much?

Nothing wrong with it if it were lynx.cfg's format from the beginning.
It happens not to be.  It seems completely pointless (except for the
fact that you are using points...) to nicify the syntax like this
without *really* soving a problem with it.  If you want to
revolutionize options & preferences handling, it would make sense to
start with studying the various ideas that have already been suggested
(but not implemented AFAIK) for somehow unifying the mechanisms for
lynx.cfg, .lynxrc, command line flags, etc.  (That would probably mean
spending some quality time with a search engine...)  I'm sceptical about
those, too... but at least they have long-term goals that make sense.

>    Seems you don't like the idea of synonims for options. OK. How about this:
> 
> CHARSET.OUTGOING_MAIL
> CHARSET.DISPLAY:
].....[
> 
> <not all current options were covered>

It would be nice if *some* options were more logically / systematically
named.  I don't think using dots vs. underscores does much to improve
that.

Now explain what equivalent changes to make to command line flags and
.lynxrc saved options and userdefs.h, and suggest a migration strategy
(including for the documentation), and I might start to take it more
seriously...

>  IMO the names are more self-documenting (at least they tell what category the
> options control).

So you don't trust cfg2html.pl much for telling the category, hm?

  Klaus