[Top][All Lists]

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

Re: [Lynx-dev] lynx2.8.7dev.5 (pretty-src improvements)

From: Thomas Dickey
Subject: Re: [Lynx-dev] lynx2.8.7dev.5 (pretty-src improvements)
Date: Mon, 28 May 2007 08:26:30 -0400 (EDT)

On Mon, 28 May 2007, Rado S wrote:

=- Thomas Dickey wrote on Mon 28.May'07 at  8:05:12 -0400 -=

iirc, the detail I fixed was where the parser ate newlines.
For the cases I was viewing (one of the ones you referred to),
the pretty-source picture had all of the newlines rendered properly.

Uh, how would you/I notice this, wouldn't this require to see the
raw data not fetched by lynx to compare it with what lynx does with
it? I always trusted on lynx preserving the raw source as it is. :-/

I was running 'screen', with vile showing the file in one tab, and
lynx in another. So (disregarding coloring), I could see that the
files had the same text in the same positions.

You mean "_not_ same positions"?!
Because, when you could see that _before_ the patch, there wouldn't
have been an indication of something wrong?!

I think we're talking about the same thing.  Before the patch I could
see that lynx displayed some lines joined together.  After the patch
they were not joined (and matched the positions shown in a text editor).

b) what kind of "cell" you mean here? (or you meant "call")?
I guess I don't understand the Style-Cache concept well enough.
AFAIUnderstood, it's only relevant for moving the highlight across
links, why would that affects passive elements?!

iirc, the cache is keeping track of the style which was used for
each cell on the screen (why, I don't recall finding out...)

.... *scared of looking at that code again* ...
But eventually I guess I'll have to ... my problems _sound_ so
trivial to fix. I'll see what I can do.

even trivial fixes can take a while (I just spent 4-5 hours analyzing a trivial bug ;-)

Thomas E. Dickey

reply via email to

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