From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Reiner Steib Newsgroups: gmane.emacs.bugs Subject: bug#4451: 23.1; EOL problems with vc-diff and cygwin Date: Thu, 15 Jul 2010 09:22:39 +0200 Message-ID: <87tyo1ryyo.fsf@marauder.physik.uni-ulm.de> References: <87skemzrre.fsf@marauder.physik.uni-ulm.de> <83r5u6wqvs.fsf@gnu.org> <20090917162612.l0stf7ln28gc4s8o@imap.uni-ulm.de> <20090918132946.w1z9vf7py8ow8ggo@imap.uni-ulm.de> <87skec9t1k.fsf@marauder.physik.uni-ulm.de> <83eipuu9dz.fsf@gnu.org> <87iqf68611.fsf@marauder.physik.uni-ulm.de> <834oqqt63w.fsf@gnu.org> <20091005180753.1mcmt2jzswoko048@imap.uni-ulm.de> <83fx9xo8vz.fsf@gnu.org> Reply-To: Reiner Steib NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1279179038 6302 80.91.229.12 (15 Jul 2010 07:30:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 15 Jul 2010 07:30:38 +0000 (UTC) Cc: 4451@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jul 15 09:30:36 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OZItv-0003Sj-LF for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 Jul 2010 09:30:36 +0200 Original-Received: from localhost ([127.0.0.1]:36992 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZItv-0003ju-1K for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 Jul 2010 03:30:35 -0400 Original-Received: from [140.186.70.92] (port=35988 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZItl-0003hn-7F for bug-gnu-emacs@gnu.org; Thu, 15 Jul 2010 03:30:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZIti-0000Oe-7m for bug-gnu-emacs@gnu.org; Thu, 15 Jul 2010 03:30:25 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56006) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZIti-0000OT-4m for bug-gnu-emacs@gnu.org; Thu, 15 Jul 2010 03:30:22 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OZIqT-0006r2-SK; Thu, 15 Jul 2010 03:27:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Reiner Steib Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Jul 2010 07:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 4451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug Original-Received: via spool by 4451-submit@debbugs.gnu.org id=B4451.127917879426332 (code B ref 4451); Thu, 15 Jul 2010 07:27:01 +0000 Original-Received: (at 4451) by debbugs.gnu.org; 15 Jul 2010 07:26:34 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZIq2-0006qd-32 for submit@debbugs.gnu.org; Thu, 15 Jul 2010 03:26:34 -0400 Original-Received: from mail.uni-ulm.de ([134.60.1.11]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZIm7-0006oJ-5V; Thu, 15 Jul 2010 03:22:32 -0400 Original-Received: from bridgekeeper.physik.uni-ulm.de (bridgekeeper.physik.uni-ulm.de [134.60.10.175]) by mail.uni-ulm.de (8.14.3/8.14.2) with ESMTP id o6F7McNT011228; Thu, 15 Jul 2010 09:22:39 +0200 (MEST) Original-Received: from localhost (localhost [127.0.0.1]) by bridgekeeper.physik.uni-ulm.de (Postfix) with ESMTP id 9BDD310437; Thu, 15 Jul 2010 09:22:38 +0200 (CEST) X-Face: /U7=m^"/-Dn61mAl{g9e3>\G5Tp,oEX|V)g2I1hBk\ML; )7A?6cmB-y7y?'NA^J<=oz7syB =(McAwIHgLX!.B?R3X}98d@?>CrT094KLWh]WU4gDpnL/")MS(XoQTv`Oq225uL>+; CpPXo$N5e>N> $tPd-gbB^F{gQS#1ase]XO~D4p4M"3+F-7~u]dy3I?Pb8RO*H-EFeWDUf?Rf, d]pv\Jvh2Cht!A=im yKAS2Z%Ao^;}W/qzMvMm Mail-Followup-To: Eli Zaretskii , 4451@debbugs.gnu.org, Stefan Monnier In-Reply-To: <83fx9xo8vz.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 05 Oct 2009 22:58:40 +0200") User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.1 (gnu/linux) X-DCC-x.dcc-servers-Metrics: poseidon 104; Body=4 Fuz1=4 Fuz2=4 X-Virus-Scanned: by amavisd-new X-Mailman-Approved-At: Thu, 15 Jul 2010 03:26:31 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Thu, 15 Jul 2010 03:27:01 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:38533 Archived-At: tags 4451 + patch quit ----- end of commands for control@..., bcc-ed ----- [ Sorry for the very late reply. With Stefan's patch, I had no problems so far. But an upgrade to Emacs 23.2 brought the unpatched version and thus the problem back. ] On Mon, Oct 05 2009, Eli Zaretskii wrote: >> Date: Mon, 05 Oct 2009 18:07:53 +0200 >> From: Reiner Steib >> Cc: 4451@emacsbugs.donarmstrong.com, monnier@iro.umontreal.ca >> >> The repository file (K3.xml,v) has Unix EOLs. But if I do a fresh >> checkout, I get a file K3.xml with DOS EOLs (I think this is the usual >> behavoir of the Windows cvs binaries[1] for text files unless you >> specify the switch "-ko"). > > Yes, that's normal behavior of the ported CVS. > >> However, in my workflow I overwrite the file with a Unix EOL file >> (exported from some application) > > Why are you doing that, and what is that ``some application'' which > converts the DOS EOLs into Unix? It doesn't convert EOLs. It's a commercial application (used by my employer). It stores its configuration in XML files including very limited version control. But it doesn't offer stuff like diff etc which CVS does. But we want to be able to diff revisions and/or different configuration files. So we export the config files from the application (-> Unix EOL) - more precise it is out testing environment -, add newlines to simplify diffing, review the changes and commit the file to CVS. We also specific (stable, tested) versions of the config file from CVS and import it into the application (production environment). >> Probably this conversion is also the reason that "cvs diff --binary" >> outputs "^M^M$" for the old file and "^M$" for the new file. "cvs diff" >> outputs consitent DOS EOLs (both diff markers and the text): >> >> $ cvs diff SK3.xml | cat --show-all | grep -F -v '^M' | wc -l > > It sounds like your port of CVS assumes that text files have DOS > EOLs. If you violate that assumption, it produces badly formatted > files, as far as EOL is concerned, and all hell will break loose on > you; Emacs showing the ugly ^M characters is just one of the > symptoms. > >> > Another possibility is that somewhere along the chain of processing >> > the output, we force EOL conversion to be Unix-style, instead of >> > detecting EOLs dynamically, or maybe even forcing it to DOS (if we >> > have clear evidence for doing the latter). >> >> `vc-coding-system-for-diff' returns `utf-8-unix' in both calls. > > Because the file is already visited in an Emacs buffer, I presume, and > vc-coding-system-for-diff uses that. > > So I agree with Stefan that you should simply not overwrite the > checked-out file with Unix EOLs. We could install the change > suggested by Stefan (based on this analysis, I no longer object to > it), If nobody else objects, may I install[1] Stefan's patch? Or we could make it depend on some variable as well ... --8<---------------cut here---------------start------------->8--- --- vc.el.~1~ 2010-04-03 18:26:12.000000000 +0200 +++ vc.el 2010-07-13 12:09:53.972342500 +0200 @@ -1398,6 +1398,12 @@ ;; (vc-call-backend ',(vc-backend f) ;; 'diff (list ',f) ',rev1 ',rev2)))))) +(defvar vc-coding-system-strip-eol t ;; nil + "When non-nil, don't inherit the EOL part of the coding-system.") +;; Don't inherit the EOL part of the coding-system in +;; `vc-coding-system-for-diff', because some diff tools may choose to +;; use another one. bug#4451. + (defun vc-coding-system-for-diff (file) "Return the coding system for reading diff output for FILE." (or coding-system-for-read @@ -1405,7 +1411,12 @@ ;; use the buffer's coding system (let ((buf (find-buffer-visiting file))) (when buf (with-current-buffer buf - buffer-file-coding-system))) + (if vc-coding-system-strip-eol + ;; Don't inherit the EOL part of the coding-system, + ;; because some diff tools may choose to use + ;; another one. bug#4451. + (coding-system-base buffer-file-coding-system) + buffer-file-coding-system)))) ;; otherwise, try to find one based on the file name (car (find-operation-coding-system 'insert-file-contents file)) ;; and a final fallback --8<---------------cut here---------------end--------------->8--- > but I'm quite sure this won't be the end of your trouble. For > example, Patch will most probably fail to apply the diffs, because > they have DOS EOLs while the source file has Unix EOLs. This means > that CVS merges will also fail. Etc., etc. -- that way lies > madness. Up to now, I didn't see other EOL related problems. Patch works fine with the diffs from Emacs buffer. > If you really want Unix EOLs, you will have to hack CVS to use binary > I/O. (I think you can force that by using some special Cygwin options > when ``mounting'' the volume, but don't ask me for details, because I > don't use Cygwin.) I can't do that because I don't control the cygwin configuration (and I would not like to change it since it might cause problems). > Thanks. Thanks for your help. Bye, Reiner. [1] It will take a while since I didn't set up bazaar upto now. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/