This is the mail archive of the
mailing list for the Cygwin project.
Re: emacs and cvs : ediff, merge, and ^M
- To: Chuck dot Irvine at mail dot sprint dot com
- Subject: Re: emacs and cvs : ediff, merge, and ^M
- From: kifer at cs dot sunysb dot edu (Michael Kifer)
- Date: Tue, 17 Apr 2001 22:08:36 -0400
- cc: cygwin at cygwin dot com, jwalsky at yahoo dot com, ntemacs-users at cs dot washington dot edu
this line is needed because of Mule.
However, you are using an old version apparently, because several mos ago
it was changed. 'raw-text is now used.
Can you check if this also solves the problem you describe?
(I recall that this was hashed out with a number of NT users as well.)
> 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
> (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.
> -----Original Message-----
> From: jwalsky [mailto:email@example.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
> 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
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple