lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev [PATCH] misc [VH] changes


From: Klaus Weide
Subject: Re: lynx-dev [PATCH] misc [VH] changes
Date: Sat, 30 Oct 1999 10:04:31 -0500 (CDT)

[ I have not tried the patches yet, just some comments ]

On Fri, 29 Oct 1999, Vlad Harchev wrote:

> * Old psrcview bug fixed  - markup was unbalanced in some situations

Does it solve the following problem?

<HTML><TITLE>test</TITLE>
some text
<UNKNOWN IRRELEVANT=something>
some text
<UNKNOWN IRRELEVANT=something>
some text
<UNKNOWN IRRELEVANT=something>
some text
</HTML>

Note how the first UNKNOWN tag with an attribute screws up the
rendering of text and tags that follow.  This probably only appears
*without* color style (please check).

It goes away when I change some of the HTMLSRC_* rules:
   HTMLSRC_ATTRVAL::
   HTMLSRC_HREF:!b:b

If that problem remains, the defaults should change (to the above
unless you have something better) so that at least it doesn't appear
by default.

> * Content of SAMP tag made justificable
(I don't think that's a word. :)) ^
> * Implemented HTStyleChange pooling - sizeof(HTStyleChange) is 4 times smaller
>     than before, and only necessary number of stylechanges is allocated now, 
>     instead of some constant (1024 by default).

Comments in your code suggest this could be used for other things.
If so that's great, code reuse is a good thing...  I couldn't see
easily how and for what, though.  Maybe you could add some more
comments.  Specifically, what is a "pool" (in the sense of your
code)?  Someone who doesn't know that (like me) may reinvent the
wheel later, which could be avoided.

> * Functionality of dont-wrap-pre improved and extened. Now it's possible to 
(typo)                                               ^
>     avoid wrapping the document being dumped completely (size of the 
> non-wrapped
>     line before the patch was limited by MAX_LINE = 1024 by default). 
> Specifying
>     -dont-wrap-pre with interactive session enables wrapped lines (in PRE) to
>     be marked as in source view - with '+' in normal view.
> * Functionality of -force-empty-hrefless-a was cleaned up, 
>     #ifndefs NO_EMPTY_HREFLESS_A and endif's were removed.
> * Colorstyle changes are not emitted in HTML_end_element if me->skip_stack 
> was 
>     >0 on entry to this function. This caused some glitches if
>     -force-empty-hrefless-a was enabled.

Not just when -force-empty-hrefless-a was enabled, if I understand
right.  It was a more general problem with tagsoup recovery.  Your
description makes it look like the change is only relevant for
'-force-empty-hrefless-a' users which isn't true.

> * LYPrettySrc.c was slightly cleaned up, added support for lynx.cfg reloading,
>     memory deallocation
> * Possible bug in print_wwwfile_to_fd fixed - when quoting the page, seems 
> that
>   several '>' could be emitted on the long line formed by concatenating ilnes 
>   with LY_SOFT_NEWLINEs at the begining of them.

See how it's growing and becoming less readable?  I think you said it
wouldn't, in connection with OUTGOING_MAIL_CHARSET discussion with Leonid.

>  General notes:
> * This patch is designed to be applied after all 4 current Klaus' patches.
> * Users that use lss-enabled lynx should consider on upgrading the lynx - at 
>  least those who use lynx for viewing huge files. By default, each line on 
> the 
>  screen took 1K for colorstyles (on x86). With new approach colorstyle changes
>  take 24 bytes (on x86) per line in average document. Old lynx with 900K html 
>  file loaded as startfile occupied 30M of virtual memory, lynx with patch 
>  applied occupied 5 Mb on the same file. Old code is still accessible by 
>  defining OLD_STYLECHANGE.

So if this works without problems, the OLD_STYLECHANGE variant and symbol
should be removed.

> * I spent 4 hours debugging attempting to write/fix code that cleans up the 
>  memory allocated in LYPrettySrc.c, but Lynx.leaks shows that I didn't 
>  succeeded. I fear that leak detection stuff is broken - I checked/traced the 
>  code very carefully several times. 

I doubt that it is broken.  I will check eventually (may take some time).



reply via email to

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