Re: LYNX-DEV No links, etc, at www.plextor.com

[Al Gilman]

  From: address@hidden (Larry W. Virden, x2487)
  
  > In the example quoted above, the commented-out example is the
  > _opposite_ of the compilation default, whereas in other places in
  > lynx.cfg the commented examples are _equivalent_ to the
  > compilation defaults.
  > 
  > Having the commented examples be the compilation defaults is probably
  > safer, and makes changing the compilation defaults more work.
  
  
  I assume that what you are proposing here is that the lynx.cfg and userdefs.h
  be set up so that the comments and values set in them reflect the default
  values in the source code, so that someone doesn't look at
  an entity that is commented out and think that's the value they will be
  getting.

I started to propose that, and then I realized that I don't know
the breadth of 'Net tools well enough to assess what is the most
common practice.

So I stepped back to say the practice should be consistent.

I think that .elm/elmrc follows the guideline above.
Some parts of lynx.cfg follow this guideline now.
We can't apply this as a blanket rule because we want examples in 
lynx.cfg -- e.g. of downloader definitions that preserve
filenames -- which do not correspond to a "compilation default" of
anything.

Maybe I would rephrase the policy proposal this way: if there is
a compilation default, it should be documented in "commented-out
user-definition" syntax.  This should be the first example when a
range of examples are provided.

In fact, these should probably be explicitly annotated as defaults,
something like:

#HISTORICAL_COMMENTS:FALSE # Default set by userdefs.h

This has benefits both for communicating what the default is,
(where it comes from) and communicating how the user should
express settings.

Al Gilman
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;