monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: Bug in CRLF conversions


From: Richard Levitte - VMS Whacker
Subject: Re: [Monotone-devel] Re: Bug in CRLF conversions
Date: Mon, 30 Jan 2006 06:34:31 +0100 (CET)

In message <address@hidden> on Sun, 29 Jan 2006 16:26:13 -0500, Yury Polyanskiy 
<address@hidden> said:

ypolyans> On Sun, 2006-01-29 at 21:32 +0100, Richard Levitte - VMS Whacker 
wrote:
ypolyans> 
ypolyans> > Nope.  Consider a binary file, which might contain
ypolyans> > anything and let's consider a get_linesep_conv that always
ypolyans> > returns {"LF","CR"} (because we run it on Mac, that's
ypolyans> > why).  Let's use a hypothetical monotone that
ypolyans> 
ypolyans> Well I wasn't thinking about LF<->CR case. For LF<->CRLF or
ypolyans> CR<->CRLF this works.

Oh, so you mean that in the LF<->CRLF or CR<->CRLF case, you're not
going to find embedded LF or CR in the binary that gets wrongly
"converted back" to CRLF?  Why would you think that wouldn't happen?

ypolyans> Some motivation why maybe it still should be done. Why we
ypolyans> want line endings translation at all? Because frigging
ypolyans> windows software doesn't handle lone \n's or \r's very well
ypolyans> (notepad, etc). Mac software I believe is much better in
ypolyans> this respect so they can live w/o translation.  Can anyone
ypolyans> using Mac comment on this?

The operating systems usually don't care about line endings, it's the
utilities that do.  Try 'cat' with a file that has \r as line endings
on most Unix systems, and you will see one fluttering line.  Some
editors have a bit of difficulty with "strange" line endings.

ypolyans> And in any case currently we have "surprising" conversion
ypolyans> for all cases and I suggest that we have "surprises" only in
ypolyans> (super rare?) LF<->CR case. Not to say that non-surprising
ypolyans> implementation 'd be much faster.

Yes, you're entirely correct, monotone has a surprising behavior, it
misbehaves with binary files because it doesn't currently handle them
properly.  For real text files, I don't see why it shouldn't be able
to handle all possible line endings in one go, just like those fancy
editors on Windows.  Haven't you ever been sent a file from someone
that works on Windows and only discovered after a while that that file
has CRLF as line endings, and gotten into all kinds of trouble because
of it?

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         address@hidden
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis




reply via email to

[Prev in Thread] Current Thread [Next in Thread]