lynx-dev
[Top][All Lists]
Advanced

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

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


From: Vlad Harchev
Subject: Re: lynx-dev lynx2.8.2dev.25d-cpp.patch.gz
Date: Wed, 5 May 1999 08:47:38 +0500 (SAMST)

On Tue, 11 May 1999, Henry Nelson wrote:

> >  The main "functionality" of that patch was providing structured
> > description of settings in lynx.cfg with alphabetical and categorized
> 
> This could be done better by simply rewriting lynx.cfg in its entirety.
> Alphabetical ordering is of marginal benefit. Categorizing by function
> is useful. The "functionality" you propose is done quite easily with the
> "/" search command available in any editor.

  How will you do categorization with editor? As for me, I start studing each
software tool by examining switches (and configuration parameters) it accepts.
I think I would found such indexed and categorized description very useful.
 
> > default values of settings wasn't it's primary purpose, but valuable
> > (for somebody) addition.
> 
> I'd like to know who that "somebody" is. For some novice users, it could
> be a source of confusion and frustration.

  The input file is processed by CPP, so it's possible to remove section
'Default value' (slighlty modifing body.in and defining some macro that will 
turn of generation of section 'Defaul value').
 
> >  It's like normal help file. If you don't read it, it doesn't mean
> > that it should be removed from distribution.
> 
> I am not proposing that the distribution lynx.cfg be removed. Quite
> the contrary, I would encourage anyone interested in furthering the
> cause of Lynx to go through that file and reorganize it and reword it to
> make it more understandable. I am opposed to duplication of content and
> forcing the entire 90kB file to be installed on a system. I am opposed
> to creeping featurism. Lynx.cfg is a file to be edited and then read by
> lynx. Functionality to make those ends easier/faster/more economical are
> meaningful. I'd sure hate to evolve into a dinosaur.

  Changes I propose is to use 'body.in' for generation of body.html _AND_
lynx.cfg (my previous path does it - check it out), so there won't be
information duplication in distribution. OK, after both of them are generated, 
they will contain nearly the same information, but in different formats. If
user has desire to print it, *.html files will be much more useful for this.

> 
> __Henry
> 

 Best regards,
  -Vlad


reply via email to

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