Extending FileList with CrLf
ned at bike-nomad.com
Wed Jul 23 00:53:01 UTC 2003
On Tuesday 22 July 2003 04:48 pm, Andreas Raab wrote:
> > So if you have a file that starts off with CR line ends, and has
> > a chunk with CRLF line ends later, you'll have garbage LF
> > characters.
> Nope. Did you ever try it? Look at CrLfStream>>next as an example:
You're right (as always!). That's what I get from relying on memory. I
remember seeing the search for the line end.
The only non-write method that looks at lineEndConvention is
#convertStringToCr:, which doesn't seem to be called from anywhere in
There were some cases where the CrLfFileStream conversion didn't do
what I wanted when dealing with some text files out of CVS:
These files had CRLF file endings, but were checked into CVS on a Unix
system. Which then stored each line as a line of text that happened
to end with a CR character.
When these were checked out of CVS onto a Windows system, the line
endings ended up as CRCRLF.
Which is why I thought (and still think) that it's reasonable to look
at CRCRLF (or LFCRLF or similar) as single line-ending characters.
If a file has a consistent use of either sequence, it's correct to
interpret each one as a single line ending.
The only place you'd make a mistake might be at the boundary between
two chunks of text that have different line endings. And the mistake
would be to miss a blank line.
I'd rather have an occasional blank line missed than to have text that
has an extra blank line for *each* line of text, which is what would
happen if we limited the line ending logic to CR,LF, or CRLF.
So I think that my counting algorithm (or more likely a state-machine
version of it) will result in better handling of damaged files.
GPG key ID: BEEA7EFE
More information about the Squeak-dev