Re: Handling sites that don't send content-type (was: lynx word bleeding?)

Thomas Dickey wrote:

> > In #1, the system setting will override STARTFILE; you'll only see
> > abc.def if the system didn't specify STARTFILE.  In #2, your setting
> > always overrides.  Either could be what you mean, you just have to know
> > what it is that you mean to mean...
>
> I'd regard that as obvious: lynx processes the configuration information
> in the order that it's given.  The existing wording in lynx.cfg suggests
> using the include first, and then your own customizations.

Of course it's obvious to someone who's been working on the code for
decades :)

This is always a question with any sort of settings-with-includes setup.
Sometimes the settings act like constants -- first mention wins, others
either produce warnings or are ignored.  Sometimes they act like
variables -- last mention wins.  Sometimes the winner depends on which
input files are 'privileged' (like the system-owned lynx.cfg).

> (patches for suggested improvements appreciated)

  # and now your own tweaks.
  #
+ # Lines are scanned in the order seen and the last mention of a setting 'wins'.
+ # To provide defaults which you will allow the INCLUDE to supersede, list them
+ # first.  To have your own settings take precedence, list them last:
+ #
+ #   # System admin may want to override this huge SESSION_LIMIT
+ #   SESSION_LIMIT:50000
+ #
+ #   # Pick up local settings
+ #   INCLUDE:/usr/local/lib/lynx.cfg
+ #
+ #   # But my STARTFILE rules supreme!
+ #   STARTFILE:https://my.favorite.site/
+ #
  # Starting with Lynx 2.8.2, the INCLUDE facility is yet more powerful.  You can
  # suppress all but specific settings that will be read from included files.

> > PS: there's also a LYNX_CFG_PATH environment variable.  A system admin
> > could do something like:
>
> in the manual page:
>
>    LYNX_CFG_PATH    If set, this variable overrides the compiled-in
>                     search-list of directories used to find the
>                     configuration files, e.g., lynx.cfg and lynx.lss.
>                     The list is delimited with ":" (or ";" for
>                     Windows) like the PATH environment variable.

Right, I just mentioned it because not everyone has read or fully
absorbed the man page.

> > - add ~/lynx/lynx.cfg to standard files created at account creation time
> >
> > - it contains 'INCLUDE:/correct/path/to/that/systems/lynx.cfg' followed
> >   by an 'overrides go here' comment
> >
> > - set a systemwide LYNX_CFG_PATH environment variable which points to
> >   the user path first; or compile it directly into the Lynx binary
>
> actually, the admin might read the install-instructions and compile-in
> a suitable value (environment variables are for users)

As I said.

Anyway, 'might' is the key word.  People don't read manuals, it's best
to bludgeon them over the head with the needed info right at the point
of need.  I mean, it's better anyway, in an absolute sense.  Was life
better when memory DIMMs were all anonymous and you needed a parts
catalog to figure out which was a 2MB-ECC vs. an 8MB-parity stick?  Or
now, when every unit is clearly labeled with its size, speed,
manufacturer, and as much bling as they can manage to squeeze on
(possibly including a little LCD which plays Doom with itself)?

>Bela<