Re: lynx-dev where is 2.8.2???

[Henry Nelson]

>    I'll start reviewing your patch.

I'd like to apologize to everyone again for causing so much trouble
and commotion.  I'd also like to thank everyone, especially Leonid,
for having the patience to wait.  Now that the integration is about
to take place, I'll recapitulate my concerns as succinctly as I can.
They are meant in a constructive tone.  If you read anything else into
them, I cannot help that other than to say I am sorry.

1) Personal, stylistic preferences should not be included in distributed
html documents, IMO.  Attempts to make the visual or printed presentation
"pretty" _for the sake of aesthetic appearance alone_, should not be allowed.

2) Since lynxcfg.html is meant to be a replacement for the annotated
text version of lynx.cfg, there will no longer be a need to couple the
'install-cfg' target with the main 'install' target. In other words
"install-cfg" should be removed from ca. line 302 of makefile.in:
   install: lynx$x install-bin install-man install-cfg @INSTALL_LSS@
If this is not possible or is not portable, then some alternative, such
as stripping lynx.cfg of comment lines before copying it, should be
considered.

3) I won't harp on this much since I realize few, if anyone, sympathizes
with my thoughts on the advisability of including the feature.  However,
it is my belief that for some document or feature to be effective,
it needs to be designed and focused with the needs of the intended
user in mind.  I never really got an answer to my question, "who is
going to use this," but I don't think it is unfair to infer that the
author intended the enhanced function for ISPs or power installers.  If
that is the case, then IMO common etiquette dictates that the feature
should be modularized and ifdefed out by default so that average users and
386dos/win32 users are not burdened with something that does not apply
to them.  If I am wrong in my evaluation, and the author intended the
feature for average, or even advanced, users, then I think there is a
lot of room left for improvement to make the feature worthwhile for
these people.  I still maintain that simplifying and streamlining the
configuration process would preclude the need by end users for this
feature (and LYNXCFG in general).

FWIW, I have some suggestions.  One possibility that might be explored
is to put LYNXCOMPILEOPTS, LYNXCFG, LYNXCFGSTATUS functions within the
NO_OPTION_FORMS define.  I tend to think that people who don't want the
forms-based options screen are likely to not want the others either.  I
also think it would be more appropriate to have all of the configuration
information available off of the O)ption form than to have some on the
=)Information page, and some duplicated on both.  Why not move all of it
from the =)Information page to the O)ption form?  The =)Information page
is supposed to be information on the current document (and link), not
information about Lynx.

__Henry