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

[Rado S]

=- Thomas Dickey wrote on Sun 27.May'07 at 11:13:58 -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. :-/

(or I misunderstand the whole case)

> Since I'd not put out a patch since November, I thought it would
> be better to get one out than spend another 5-6 months fixing
> everything...

Thank you :)

>> WOW, this actually solves my example page with the "too long
>> TEXTAREA" and "FORM elements when they are below line 64"!
>> Now that I see what this does, I understand why it helps.
>> Although I wonder why with CACHEW 128 in my 150 wide terminal and
>> TEXTAREA cols=140 only the lines > 64 were miscolored, while the
>> columns > 128 were still ok. :(
>
> Perhaps it was addressing the next row in the cache for the
> "working" case, and that happened to look ok. Someone commented
> recently that the cache logic assumes only one hit per cell.

a) the first part makes no sense to me. :) The columns beyond limit
were never miscolored, even at the borderline of the miscolored
lines, where the next line wouldn't be ok anymore.

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?!

-- 
© Rado S. -- You must provide YOUR effort for your goal!
EVERY effort counts: at least to show your attitude.
You're responsible for ALL you do: you get what you give.