lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Vlad Harchev
Subject: Re: lynx-dev Re: what to do about html help files.
Date: Wed, 26 May 1999 11:01:35 +0500 (SAMST)

On Fri, 28 May 1999, Doug Kaufman wrote:

> On Tue, 25 May 1999, Vlad Harchev wrote:
> 
> > ...
> > we have to force like STARTFILE, so no documentation comments will be in the
> > lynx.cfg. This will reduce distribution size and startup time.
> >  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
> > rendering (tho' maintaining comments is not techincally difficult)?
> 
> I think that this will make configuring lynx MUCH more difficult. Now,
> the key documentation is next to the place where the setting is done.
> While within the editor, appropriate choices can be made. If this
> documentation is taken out of lynx.cfg and only available in html,
> then for every question about a lynx.cfg setting, lynx will have to
> be started to read the html (or read it raw in the editor or viewer).
> Especially on initial setup of lynx, this creates a "catch 22", i.e.
> you need lynx configured and running to read the file on how to do the
> initial configuration.

 Having small lynx.cfg is an advantage - user don't have to search for
initilaization of settings through such huge pieces of comments (of course rx
serach will help very much, but not all users know how to use rx) - seems that
it will take  not more than 3 screens for average users.
 IMO we can make a configure option that, if specified, will strip all
comments from installed lynx.cfg (and make this option disabled by default).

> Why is it good to have documentation in "billions of renderings"?

 Because html can be rendered by lynx on terminal of any width, while
lynx.cfg looks reasonably on terminals with more than 80 cols only.

> Plain text is still best read with a text viewer, not a html renderer
> (at least as far as I am concerned).

  Agree for plain text.

>[...] 

 Best regards,
  -Vlad


reply via email to

[Prev in Thread] Current Thread [Next in Thread]