Re: lynx-dev lynx2.8.2dev.25d-cpp.patch.gz

[Vlad Harchev]

On Tue, 11 May 1999, Henry Nelson wrote:

> > independent of lynx configuration (now all is portable!!!).
> 
> Again, no hype, i.e., "!!!", please. Give us a chance, too.
> 
> >   I've added support for special URL type - LYNXSETTINGSTATUS. For
> > example, to get the status of the setting COLOR, you should use the
> > following url: LYNXSETTINGSTATUS://COLOR
> 
> Nice. However, if this whole idea is to be useful to the people it is
> intended for, the content must be meaningful to _them_.

  What do you suggest except removing something? 

> >    This setting is ignored by current configuration of Lynx. This
> >    setting aggregates its values.
> 
> So my immediate question is, "why is it ignored?", and "how do I get it
> un-ignored, i.e., how do I set it." What does "aggregates its values"
> mean?

  Just FYI, I compiled lynx with color-style, so it's really ignored.

  OK, we can be more descriptive at this point. We can substitute the 1st
sentence with "This setting is ignored by current configuration of Lynx due to
the way it was configured." I don't know how to paraphrase the 2nd sentence - 
it means that this initializing the setting won't throw away the value it was
assigned before - ie COLOR is like UPLOADER, aggregate assigned values (to be
frankly, not exactly - it doesn't aggregate values in true sense). Anyway,
we can remove this sentence.
 
> >    The default value(s) for this setting can not be altered in
> >    'userdefs.h' at configuration time.
> 
> So, again, just where can it be set? If, as Larry points out, and was
> my initial point I hoped someone would drive home, this "functionality"
> is for the user who is not in a position to do the compiling and
> configuring, then this statement serves no purpose. This user doesn't
> know what userdefs.h is, and even if he/she did, it would do him/her no
> good. Anyone who has edited userdefs.h knows that fact.

   This can be useful for sysadms (they can't remember everything).
> 
> > Here is a default value of this setting:
>           ^
> "the"?  Anyway, I question the need for spitting out the default.

  Yes, may be "the". As for default, you can scroll it down and don't read. If
you didn't initialize this setting in any of your conf. files, then you won't
have the way to tell it's current value (if you don't know what was
'default'). If this happened, my patch will write:
    "This setting wasn't initialized in configuration files, the default
value remains.the default value remains."
 so it won't dump current value (=default value) again.

 Information about default can be useful for other people (to analyze the
current value and the value that was distribution default - at least the
syntax).
 
> >   Current value
> >
> >    Here is a list of values that were aggregated while
> > reading configuration files: COLOR:0:lightgray:black
> > COLOR:1:brightmagenta:black COLOR:2:green:black COLOR:3:green:black
> > COLOR:4:cyan:black COLOR:5:red:black COLOR:6:brightred:black
> > COLOR:7:magenta:cyan
> 
> Now we are finally getting to the meat. This is what the user wants to
> know. The only other thing he/she wants to know is how to change it.

 I assume user has reached this page from the - body.html -  right from
description of this setting (so (most probably) the user knows what this
setting deals with). But we can add a link to lynxcfg/body.html#COLOR, for
reference information on this setting (may be wise idea).

> >   Assigment trace
> >
> >    Here is a trace of files and lines in which this setting was
> >    initialized ([1]go here to see a trace for all settings):
> >
> >    file [2]/usr/local/lib/lynx.cfg 1736=>COLOR:0:lightgray:black
> > 1738=>COLOR:1:brightmagenta:black 1740=>COLOR:2:green:black
> > 1741=>COLOR:3:green:black 1742=>COLOR:4:cyan:black
> > 1743=>COLOR:5:red:black 1744=>COLOR:6:brightred:black
> > 1745=>COLOR:7:magenta:cyan
> 
> There is no need for both. It is a total waste and only confuses the
> issue. Tell your user what his/her color setting is. Then tell him/her
> to copy /usr/local/lib/lynx.cfg to $HOME, edit lines 1736-1745 (with
> the explanation in the default lynx.cfg file in case the installer has
> zapped all the comments), and then run lynx with the -cfg option or set
> the environmental variable.

  Values of "scalar" settings are overwritten after each assignment, so it's
useful to have a trace of whether this setting was initialized. If you use
'INCLUDE' directive in your cfg.files, then you won't know definitely where
(in which file) initialization happened.

> > IMO it worth including it in 2.8.2. I tested it extensively.
> 
> IMHO unless it is tuned to the end user of the binary who has no
> control over the default settings, it is pointless. I mean, the person
> who edited lynx.cfg in the first place doesn't need it. Already this
> information is readily available through the `=' page. Personally, I
> either view it as a localfile:// to be able to edit it, or throw it into
> the editor outside of Lynx.
> 
> __Henry
> 
  We can add command-line switches that will tune contents of this page
(probably to reduce some information), but I don't think it's reasonable.

 With future in mind, we can provide the means of editing the value of each 
setting - provide a textarea or inputline, so the user will be able to change
simple settings at run-time (if not restructed) (this is bold idea, but it
should be considered) -at least lynx can generate and  append new 
initialization of this setting to some file that will be included by main 
configuration file.

 From my point of view, thing that is useful of part of the people, and not
harmful for others, should be considered useful and worth including it in
distribution. And you personaly, can don't install generated *.html files this
patch adds, and don't visit LYNXSETTINGSTATUS://*. But let's think on 
improvements of this page.
 
 Best regards,
  -Vlad