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: Leonid Pauzner
Subject: Re: lynx-dev lynx2.8.2pre.7
Date: Wed, 26 May 1999 21:07:11 +0400 (MSD)

26-May-99 07:47 Webmaster Jim wrote:
> On Wed, May 26, 1999 at 08:32:55AM +0400, Leonid Pauzner wrote:
>> 25-May-99 19:59 address@hidden wrote:
>> I have a look at lynx executable size and lynx.cfg size for 2.6, 2.8, 2.8.1,
>> 2.8.2 both expanded with the same speed (and lynx.cfg groth a little faster),
>> with the factor of 2 between 2.6 and 2.8.2. So catalog to navigare across
>> lynx.cfg is a good idea, we could not insist users to read this file several
>> times just to know that the new features are: they ask us questions, but FAQs
>> mot maintained now.  Hmm, I've speak out.

> Speaking of FAQs, I'm contemplating updating the one at SLCC. I found
> some nice tools to do that. Volunteers to assist maintenance send me
> email off the list (or use the list elves list).

> As far as changes, a code freeze is a code freeze is a code freeze.
This one not a code, just a new documentation file(s).

26-May-99 10:35 address@hidden wrote:
>>
>> 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.


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.

> 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.


> 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.

> 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.
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.


> __Henry

> The w3c validation service has this to say about body.html:

>                     [3]W3C HTML Validation Service Results

>    Below are the results of attempting to parse this document with an
>    SGML parser.
>   __________________________________________________________________________


> Error at line 1:
>    <html><head>
>     [7]^  Missing DOCTYPE declaration at start
>  of document ([8]explanation...)
>   __________________________________________________________________________


> Error at line 9:
>    <h2><div align=center><tt><a name="STARTFILE"></a>STARTFILE</tt>&nbsp; 
> [9][.
> ..]
>                         [10]^  document type does not allow element "DIV" 
> here;
>  missing one of "APPLET",
>           "OBJECT", "MAP", "IFRAME", "BUTTON" start-tag
>   __________________________________________________________________________


> Error at line 37:
>    <h2><div align=center><tt><a name="HELPFILE"></a>HELPFILE</tt>&nbsp; - 
> [11][
> ...]
>                         [12]^  document type does not allow element "DIV" 
> here;
>  missing one of "APPLET",
>           "OBJECT", "MAP", "IFRAME", "BUTTON" start-tag
>   __________________________________________________________________________


> Error at line 58:
>    <h2><div align=center><tt><a name="DEFAULT_INDEX_FILE"></a>DEFAULT_IND 
> [13][
> ...]
>                         [14]^  document type does not allow element "DIV" 
> here;
>  missing one of "APPLET",
>           "OBJECT", "MAP", "IFRAME", "BUTTON" start-tag
>   __________________________________________________________________________


> Error at line 74:
>    <h2><div align=center><tt><a name="GOTOBUFFER"></a>GOTOBUFFER</tt>&nbs 
> [15][
> ...]
>                         [16]^  document type does not allow element "DIV" 
> here;
>  missing one of "APPLET",
>           "OBJECT", "MAP", "IFRAME", "BUTTON" start-tag
>   __________________________________________________________________________




reply via email to

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