Re: lynx-dev [PATCH 2.8.3.dev6] fixes for psrc mode

[Leonid Pauzner]

14-Aug-99 18:17 Vlad Harchev wrote:
> On Mon, 16 Aug 1999, Leonid Pauzner wrote:

>> 13-Aug-99 01:45 Vlad Harchev wrote:
>>
>> > * Now LY_SOFT_NEWLINE are used in psrc mode to denote wrapped lines (as in
>> >   plain source mode).
>>
>> Using this patch, still have a difference
>> between "normal" source and prettysrc output Re: line breaks.
>>
>> 1) LY_SOFT_NEWLINE inserted in a wrong place ( < line width)

>  Can you give an example?
I see this on my display but printing out to local file
concatenate lines so... it is not so easy to made hard copy for you.

>> 2) when printing source to the file we got different output (lines still
>> truncated, at least HREF= URLs, see example below).
>> 2b) unexpected lost of space between words in anchor title (example below).

>  Very interesting.

>  This is a diff I see on my Linux (for the same document):
> =======================================
> --- plain-src.html    Sat Aug 14 17:58:28 1999
> +++ prettysrc.html    Sat Aug 14 18:04:47 1999
...
> =======================================
>  I have lss-enabled lynx-2.8.3dev6-patched being used under linux 80-cols
> console.
>  What lynx do you have?

I have 2.8.3dev6 without lss support (in fact, this is a DJGPP compiled
DOS version I am playing with on my PC). I use PDCurses. 80-cols display.

>  As for 'NCSAMosaic' - this problem seems to be caused by the fact, that
> GridTextc:split_line removes trailing whitespaces (but why it didn't happen in
> plain src mode? - I thought it won't remove anything trailing if
> LY_SOFT_NEWLINE is at the end.. ). I'll inspect this.
>  BTW, if you can make your 'diff'ing easier, if you insert following lines in
> your lynx.cfg:

> HTMLSRC_TAGNAME_XFORM:1
> HTMLSRC_ATTRNAME_XFORM:1
>  -this will leave the case of tagnames and attrnames in psrc mode.
No problem,
I just made them different intentionally.

>  And don't forget that attributes are converted to the display charset, so
> you'll probably won't get exactly the same document.

Both variants are converted to display charset (at least they should);
and the document in question was 7bit only...

>  Best regards,
>   -Vlad