[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
Re: lynx-dev lynx2.8.2pre.7, Henry Nelson, 1999/05/26
Re: lynx-dev lynx2.8.2pre.7, dickey, 1999/05/26
Re: lynx-dev lynx2.8.2pre.7, Henry Nelson, 1999/05/26
Re: lynx-dev lynx2.8.2pre.7, dickey, 1999/05/26
Re: lynx-dev lynx2.8.2pre.7, dickey, 1999/05/27