lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev lynx2.8.2pre.7


From: Vlad Harchev
Subject: Re: lynx-dev lynx2.8.2pre.7
Date: Mon, 24 May 1999 18:20:35 +0500 (SAMST)

On Wed, 26 May 1999, Leonid Pauzner wrote:

 This message should be considered also as an answer to Henry Nelson (I've
deleted his huge message so I reply to this)

> >> At the very least, html supplied in the lynx distribution really needs to
> >> validate to an included publically accessible DOCTYPE.  Lynx html should 
> >> also
> >> use only the HTML that one would get regardless of the configuration (not
> >> that the pages in questions violate this - just thinking out loud at some
> >> of the standards for lynx html that we should write somewhere in the
> >> distribution).
> >>
> >> Lynx's lynx.cfg information page seems sufficient to me.
> 
> > same here.  (none of my concerns about lynxcfg have been addressed, though
> > I'm willing to adjust the configure script to make it simpler for Vlad to
> > make it an add-on)
> 
> Not agree, still.

  Me too. 

> 
> 26-May-99 09:58 Henry Nelson wrote:
> >> I still insist on removing po/*.po files from distribution
> 
> > No argument here.
> It was in another mail: *.po files expected to be maintained _after_
> 2.8.2 release (lynx.pot will be frozen but *.po will drift to fit tamplate
> one day).
> 
> 
> >> and adding lynx_help/lynxcfg/{body.html,cattoc.html,alphatoc.html} files
> 
> > I cannot out of all conscience second this motion.  I have gotten no
> > straight answers and nothing but verbal abuse from my questions.  What
> > is wrong with asking?  The purpose is to strive for a quality product.
> 
> What quality of questions?
> Abusing lynx-dev with 500K e-mail isn't a good idea.
> 
> >> These files should be installed with "make install-lynxcfghelp".
> 
> > This adds to Tom's burden and slows down the release.  Somebody has
> > to write the target, and then maintain it.
> 
> We have install-help, this almost the same (just another directory).
> So no problem.
 
 Agree.

> > My question was quite simply:
> > How is body.html so much better than the original distribution lynx.cfg?
> 
> It is better because of the presense of cattoc.html and alphatoc.html.
> First one is essentially useful since help in finding appropriate option
> quickly.
> 

 And due to output-device independancy and being hypertext. User can quickly
browse the description of settings related to the setting he is exploring.

> > Here is an example.  I loaded body.html and lynx.cfg into Lynx, and then
> > did a search (/) on "HISTORICAL".  The P)rint to disk of the respective
> > content was, body.html:
> 
> >                   HISTORICAL_COMMENTS  - [390]HTML parsing
> 
> >   Description
> 
> >        If HISTORICAL_COMMENTS is TRUE, Lynx will revert to the
> >    "Historical" behavior of treating any '>' as a terminator for
> >    comments, instead of seeking a valid '-->' terminator (note that white
> >    space can be present between the '--' and '>' in valid terminators).
> >    The compilation default is FALSE.
> 
> >        The compilation default, or default defined in configuration file,
> >    can be toggled via a "-historical" command line switch, and via the
> >    LYK_HISTORICAL command key.
> 
> >   Default value
> 
> >       HISTORICAL_COMMENTS:FALSE
> 
> >   Status
> 
> >       [391]View status of this setting.
> 
> 
> >      _________________________________________________________________
> 
> > and lynx.cfg:
> 
> > # If HISTORICAL_COMMENTS is TRUE, Lynx will revert to the "Historical"
> > # behavior of treating any '>' as a terminator for comments, instead of
> > # seeking a valid '-->' terminator (note that white space can be present
> > # between the '--' and '>' in valid terminators).  The compilation default
> > # is FALSE.
> > #
> > # The compilation default, or default defined here, can be toggled via a
> > # "-historical" command line switch, and via the LYK_HISTORICAL command key.
> > #
> > #HISTORICAL_COMMENTS:FALSE
> 
> > For me personally, the plain text rendition is easier to read because it
> > takes up only 1/3 of my screen.  The html version spans nearly two pages
> > so I have to flip back and forth.  The content is virtually the same.

 For me (with lss enabled, with -lss=mild-colors.lss) html rendition looks
very cool (much better than lynx.cfg).

 Have you (NH) tried browsing lynx.cfg on terminal less than 80 chars wide ?
 (say 50) - you'l have to scroll the screen back and force to read each
sentence. No problem with html - lynx formats it for current terminal width.
 Have you (HN) tried browsing lynx.cfg on terminal more than 80 chars wide ?
(Each line in lynx.cfg is shorter than screen width). 
 Have you (HN) tried to prettyprint it?

 As for space between setting descriptions, I did it so big since I considered
that such big gap is more visually attractive than 1-line gap. If you
don't think so, then 
 sed -e 's|<pre> </pre><pre> </pre><hr><p>|<hr>|' body.html > body1.html
and enjoy body1.html.

> > My second comment was that alphabetization and indexing of the content
> > could be done more economically by rewriting the distribution lynx.cfg.
> > There is no reason that a table of contents and/or index could not be
> > included in lynx.cfg.  Line numbers could be included at a minimal cost
>                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> this will fall into a new problem: maintenance of line numbers(!)
> > in size.  For that matter, the whole file could be html'ized quite
> > easily in place without adding an additional file, i.e., dual purpose.

 Seems much less elegant than plain html (and indeed requires a lot of work
while body.in is already written).

> Dual purposes is due to lynx.cfg nature: the file edited by hand
> but the comments should be located somethere for reference
> so always available for interested (not restricted) person.
> Your were the first who cut off lynx.cfg up to ~5 lines essential for your
> host's needs, so you delete comments occusionally.
> 
> Even worth: we support INCLUDE'ed files and support _old_ lynx.cfg's
> from previous releases, so this is a mess until we have no `read only'
> comments shipped with lynx binary of the same version.
> 
> > Something which I have not gotten into because I felt the whole idea
> > was not worth implementing, is the question "Is this the kind of
> > example of well-written html that we want Lynx documentation to set?"
> > I see no evidence of the document even being validated.
> 
> this is another question (and why not to fix it?)
> We may discuss output and it can be changed in seconds
> while template seems OK.

 Already changed. To HN: thanks for report.
 New version  of body.html is in its convenient place:
          www.hippo.ru/~hvv/body.html
 http://validator.w3.org validates it succefully. 

 Best regards,
  -Vlad


reply via email to

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