Extending FileList with CrLf

Ned Konz 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 
my image.

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.

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE



More information about the Squeak-dev mailing list