[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev Potential patch for HTFTP.c
From: |
Patrick |
Subject: |
Re: lynx-dev Potential patch for HTFTP.c |
Date: |
Sun, 6 Aug 2000 12:46:31 -0700 |
In "Re: lynx-dev Potential patch for HTFTP.c"
[06/Aug/2000 Sun 07:24:15]
address@hidden wrote:
> In a recent note, Doug Kaufman said:
>
> > Date: Sat, 5 Aug 2000 23:13:12 -0700 (PDT)
> >
> > A user of the DOS port of lynx recently pointed out to me that
> > DOS mode text files (EOL=LF CR) are rendered differently by lynx,
>
> I am not a DOS user, but my understanding had been that for DOS
> EOL=CR LF.
Yes, but it's a problem many browsers have with DOS line-breaks:
Since they have to recognize UNIX and Macintosh EOL characters
as well [LF and CR, respectively], with DOS returns, each CR+LF
is often read as two *separate* line endings. You usually don't
see it unless you view source, but it can mangle a PRE block too,
especially when the block contains ASCII art.
I've seen this in Lynx [MacLynx anyway, v2.7.1 port], Netscape
3.x, and NetFinder [FTP client with some file-viewing capability,
for Read Me's and "00_index.txt" files on FTP servers].
> > following patch attempts to change the default ftp mode for viewing
> > to image, leaving it ascii when using a CMS server. Does this break
> > anything? Does anyone else think that this change is a good idea?
> >
> I'll be a reactionary here; si fractum non sit, noli id reficere.
> What problem are you trying to fix? Can you name a site and a
> command sequence that manifests the problem? How would the behavior
> differ with your patch installed?
In my experience, it seems to happen everywhere you see preformatted
text with DOS line-breaks. Never seemed like much of a problem
though, because linefeeds are so much more common.
As a general approach, would it be better to look first for LR+LF,
treating each as a single line ending, *then* look for single
CRs and LFs? That's the order in which I usually do batch
find-and-replace runs in BBEdit, and it seems to work.
> -- gil
> --
> StorageTek
> INFORMATION made POWERFUL
Patrick
<mailto:address@hidden>
; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden
Re: lynx-dev Potential patch for HTFTP.c, David Woolley, 2000/08/06
- Re: lynx-dev Potential patch for HTFTP.c, Doug Kaufman, 2000/08/06
- Re: lynx-dev Potential patch for HTFTP.c, Doug Kaufman, 2000/08/07
- lynx-dev Revised patch for HTFTP.c, Doug Kaufman, 2000/08/07
- Re: lynx-dev Revised patch for HTFTP.c, Mike Castle, 2000/08/07
- Re: lynx-dev Revised patch for HTFTP.c, pg, 2000/08/07
- Re: lynx-dev Revised patch for HTFTP.c, Mike Castle, 2000/08/07
- Re: lynx-dev Revised patch for HTFTP.c, Doug Kaufman, 2000/08/07
- Re: lynx-dev Revised patch for HTFTP.c, Klaus Weide, 2000/08/07
- Re: lynx-dev Revised patch for HTFTP.c, Doug Kaufman, 2000/08/07