Re: lynx-dev Re: what to do about html help files.

[Vlad Harchev]

On Sat, 29 May 1999, Henry Nelson wrote:

>> To all lynx developers: this message contains ideas I'd like to be read by
>> all of you.
>
>Amen to this because, besides having been driven absolutely crazy (yes,
>it's true, Leonid), I'm tired.

 Seems you'll drive me crazy too.
 
> >  As for configure script, IMO advanced users will be able to issue a 'mv -f
> > lynx.oldcfg lynx.cfg' to fix it. 
> 
> The question is more like "should they have to?".  I'm also siding with
> those sysadms (I'm one of them; that's why :) who MUST install Lynx,
> but are virtual amateurs and, on the basis of past experience, trust Lynx
> and Lynx developers to do right by them.  Some of these people don't even
> know what `mv -f` is, much less that a lynx.oldcfg was created or even
> what the path to it might be.  They type "./configure; make install."

  The people that don't know what 'mv -f' is don't build lynx, they get RPMs.
  When doing 'make install' lynx notices that lynx.cfg file was backed (as I
remember).
 
> >  IMO we can make distribution's lynx.cfg very small - less than 1KB - by
> > placing a comment like "see body.html for documentation" and few settings 
> > we have to force like STARTFILE, so no documentation comments will be in the
> > lynx.cfg. This will reduce distribution size and startup time.
> 
> I think all I've been asking for through this whole thread is some
> consideration of such alternatives.  Note that this alternative was not
> well received by one lynxdever, however.  I see some problems with it,
> but it is in fact how I handle it on both my personal and system-wide
> installations, and I like it.  I think the real solution is to put
> lynx code and the configure script in line with each other.  That is, if
> I am not mistaken, I don't think the configure script makes a distinction
> between LYNX_CFG_FILE and LIBDIR/lynx.cfg.  The Lynx code, OTOH, makes
> assumptions on the basis of the difference between these two.
   
  I don't understand what do you mean with putting lynx code and configure
script in line with each other.

> >  Having documentation in html is equal to having docs in billions of
> > renderings. Why should we maintain lynx.cfg comments that are only in one
> 
> I hate to open up fresh wounds, but this is where I have one real problem
> with body.html.  I really don't think it is fair to bundle all of that
> fancy printing/GUI markup in there.  If that's your goal, then give me a
> pdf file I can download off of your site.

    If you don't like markup (I like the markup very much with -lss=
mild-colors.lss bundled in distribution), get the /scripts patch, modify
macros and you'l get lean html. As for content:markup ratio, body.html
renderend to text is 144 kb, while body.html is 191 kb. It's size is (IMO) due
to hrefs, not markup like <b>,<em>, so IMO you won't be able to reduce the size
of body.html by more than 20 Kb preserving all hrefs.  And this file is 44 kb
gzipped.

> > > evolved into something more complex than it need be.  If the configuration
> > > process itself were simplified (or returned to its former state) there
> > > would hardly be any need for all of this.
> > 
> >  Simplification = loss of flexibility here.
> 
> Absolutely.  It's a tradeoff.  In general you have the support of the
> majority of Lynx users, so not to worry much about my comments here!

 I hope.

> >  What do you mean by intercation of settings? Does LYNXSETTINGSTATUS://
> >  suite you?
> 
> Not particularly, no.  I've said it before: it is not focused toward
> its intended audience.  It does not help the average user; it is redundant
> to the installing sysadm.
> 
> What I mean by interaction is thorough handling of not only what you call
> "aggregate" settings, but also how _different_ settings may affect other
> settings.  All I get from your present LYNXSETINGSTATUS is what I have,
> but then I already know that because I see the behavior I'm getting from
> Lynx.  In some cases knowing where in what file the setting that is in
> effect was made will help (thus, I am not at all discounting your work
> entirely) me debug my problem, but that is only because I know what each
> of those settings mean in the first place.

 User has to read lynx.cfg  or body.html. This is good documentation of how
settings interact with each other (and body.html contains a references to the 
description of all options referenced in the description of given option -
section "See Also" and hrefs in very description - IMO those hrefs help a
lot in navigating). 
  As for LYNXSETTINGSTATUS://, we can tune its content according to the value
default_user_mode or make virtual subdirs that will provide only part of all
information.
 
> >  Now I think the best way to edit setting values at run-time is to provide
>                                                    ^^
> "during" run-time?

 For me as non-native english speaker, it makes no difference :) But seems you
got the idea what I meant.
 
> >  Putting everything in options menu will require a lot of code to handle it 
> > -
> > see LYOptions.c, and multiply its size by 10 -you'll get an impression of 
> > what
> > should be implemented.
> 
> If lynx.cfg can be reloaded, i.e., changed and those changes made effective
> during a Lynx session, do we need LYOptions?  (The reverse of my question.)

 Options screen is required, since even if lynx is fully restricted and there
is not access to filesystem directly (at ISP's account), it gives ability to
change settings that are important for users but safe for security.

>[...]

  This thread is turned into  a chat :)
 
> __Henry
> 

 Best regards,
  -Vlad