Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
From: Chuck DOT Irvine AT mail DOT sprint DOT com
Date: Tue, 17 Apr 2001 20:58:29 -0500
Message-Id: <H00009db09e26195.0987559108.kcopmp06@MHS>
Subject: RE: emacs and cvs : ediff, merge, and ^M
MIME-Version: 1.0
TO: cygwin AT cygwin DOT com, jwalsky AT yahoo DOT com, kifer AT cs DOT sunysb DOT edu,
        ntemacs-users AT cs DOT washington DOT edu
Content-Type: multipart/mixed; boundary="openmail-part-2451634c-00000001"

--openmail-part-2451634c-00000001
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
	;Creation-Date="Tue, 17 Apr 2001 20:58:29 -0500"
Content-Transfer-Encoding: 7bit

Maybe I got lucky here. 

I had a hunch that the ^M characters that I was seeing in the buffer 
*ediff-fine-diff* were the cause of this problem. So, I started poking 
around to see if I could see where this buffer was being populated and 
started examining the method ediff-exec-process. Pretty quickly the 
line 
(coding-system-for-read 'no-conversion) caught my eye. Since I had 
previously thought that the problem might be related to coding-system 
effects, I commented this line out, evaluated the method, and tried 
again, just to see what happened. Lo and behold, the problem went away, 
i.e. ediff correctly identified the diffs as real instead of just a 
difference in white space. I've tried a few more things and so far it 
doesn't seem like I've broken anything. 

So, Michael, what is the purpose of this line of code? Do you think 
commenting it out will break something somewhere? Any alternative 
suggestions? Thanks.

Joshua, BTW, the first thing that you will need to do is download and 
install the latest version of ediff. Sorry, I can't remember where I 
downloaded it from. And, also, many people will ignore html formatted 
email - not sure exactly why.

Chuck

-----Original Message-----
From: jwalsky [mailto:jwalsky AT yahoo DOT com]
Sent: Tuesday, April 17, 2001 6:34 PM
To: cygwin
Cc: jwalsky; Chuck.Irvine
Subject: emacs and cvs : ediff, merge, and ^M


I saw the thread initiated by Chuck Irvine about ediff and carriage 
returns (^M) on Windows back in November, but could not find any 
resolution.
 
http://cygwin.com/ml/cygwin/2000-11/threads.html#01515

I am experiencing similar problems, both --binary not being understood 
and ^M appearing upon merge.  When files are merged through the cvs 
update command (with or without conflicts) ^M are inserted in the new 
versions.    It seems that whatever is doing the merge for cvs is 
inserting these carriage returns?  Is there any way to stop this?  Is 
this a configuration issue?  I am not too concerned about the --binary 
issue since I really haven't looked into it thoroughly enough, however, 
I could use some help with the carriage returns.

The ediff version I have is 2.70.2 (as indicated by ediff-version)
The emacs version I have is 20.7.1 (as indicated by version)
The cvs version is 1.11 (as indicated by cvs --version)
My cygwin.dll version is 1.1.8 (that is the version I downloaded... how 
can I figure this out if I forgot?)

Thanks in advance,
- joshua


--openmail-part-2451634c-00000001
Content-Type: text/plain; charset=us-ascii

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
--openmail-part-2451634c-00000001--