Re: lynx-dev Proposed patch (DOS related)

[Doug Kaufman]

On Sat, 10 Oct 1998, Leonid Pauzner wrote:

(quoting me) 
> > I am having trouble understanding the logic behind the display of
> > lynx.cfg in LYReadCFG.c. It seems to try to display a lynx.cfg file,
> > either at the site specified in userdefs.h (for VMS and those using
> > configure) or in the helpfile directory (for DOS and Win32), instead
> > of the active lynx.cfg. I am not sure that there is a reason to
> 
> It was done by me intentionally. For DOSPATH there is no standard location for
> lynx.cfg, userdefs.h set it to "." and user set it to lynx_cfg_file in
> environment or from command-line. The 'LYNXCFG_HELP' was supposed to point us
> out to clear distribution's lynx.cfg as a source for about 90Kb of comments
> (LYNX_CFG_FILE from autoconf seems to be a best candidate on UNIX).
> 
> Since lynx.cfg may now have an INCLUDE directive to render several cfg files
> recursively (and "lynx.cfg info link" from Options Menu or Info Page render
> included cfg files exactly as lynx does on startup), it may be possible (and
> reasonable) to have a small add-on file e.g. file with a single line like
> "PARTIAL:FALSE" or so. If this happen to be a small cfg file we may lost the
> comments if will use your patch.

I follow what you are saying, but disagree with the reasoning. The
question of following an INCLUDE directive is moot if the file
being rendered is NOT the active lynx.cfg, but rather a copy of the
distribution's lynx.cfg which has been saved unmodified. The change
to include a subfile will be in the active lynx.cfg. In most cases,
this will be the address from userdefs.h. Neither the individual user
nor a system administrator needs to keep lynx.cfg at this location,
however. If lynx.cfg is at another location, the current code will not
find it. "lynx_cfg_file", however, ALWAYS points to the configuration
file currently being used, which should have all the comments and
any links to included files. I won't (and I suspect most users and
administrators won't) keep a duplicate copy of lynx.cfg just for the
help system to find. If the worry is that the active file will be
shortened to only the items that are different from the compilation
option, it is easier to specify in the INSTALLATION instructions that
the file should not be shortened because it is also a help file, than
to ask that a duplicate file be kept at a hardcoded help location.

Perhaps I am missing some implications of the current code. What
allows lynx to follow included files now, which doesn't work after the
proposed patch?
                              Doug
__
Doug Kaufman
Internet: address@hidden (preferred)
          address@hidden