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

[Thomas Dickey]

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
http://invisible-island.net
ftp://invisible-island.net