From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#18236: diff-apply-hunk interacts poorly with line endings Date: Sat, 20 Feb 2016 14:16:06 +0200 Message-ID: <834md3poft.fsf@gnu.org> References: <87oabfz6xj.fsf@mbork.pl> <83twl7uw8l.fsf@gnu.org> <838u2jumb7.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1455970642 3005 80.91.229.3 (20 Feb 2016 12:17:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Feb 2016 12:17:22 +0000 (UTC) Cc: mbork@mbork.pl, 18236@debbugs.gnu.org To: Reuben Thomas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Feb 20 13:17:10 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aX6TF-0007Uc-Ql for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Feb 2016 13:17:09 +0100 Original-Received: from localhost ([::1]:60426 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aX6TE-00020C-VA for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Feb 2016 07:17:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33034) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aX6TB-0001zp-JO for bug-gnu-emacs@gnu.org; Sat, 20 Feb 2016 07:17:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aX6T8-0002A7-DO for bug-gnu-emacs@gnu.org; Sat, 20 Feb 2016 07:17:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37532) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aX6T8-0002A1-Ad for bug-gnu-emacs@gnu.org; Sat, 20 Feb 2016 07:17:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aX6T8-0002UA-5B for bug-gnu-emacs@gnu.org; Sat, 20 Feb 2016 07:17:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 20 Feb 2016 12:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18236 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18236-submit@debbugs.gnu.org id=B18236.14559705929506 (code B ref 18236); Sat, 20 Feb 2016 12:17:02 +0000 Original-Received: (at 18236) by debbugs.gnu.org; 20 Feb 2016 12:16:32 +0000 Original-Received: from localhost ([127.0.0.1]:34658 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aX6Se-0002TF-2D for submit@debbugs.gnu.org; Sat, 20 Feb 2016 07:16:32 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41827) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aX6Sd-0002T2-64 for 18236@debbugs.gnu.org; Sat, 20 Feb 2016 07:16:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aX6SU-00023O-NF for 18236@debbugs.gnu.org; Sat, 20 Feb 2016 07:16:25 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60240) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aX6SU-00023I-JY; Sat, 20 Feb 2016 07:16:22 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1479 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aX6ST-0004cO-Sy; Sat, 20 Feb 2016 07:16:22 -0500 In-reply-to: <838u2jumb7.fsf@gnu.org> (message from Eli Zaretskii on Wed, 17 Feb 2016 22:14:04 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:113357 Archived-At: > Date: Wed, 17 Feb 2016 22:14:04 +0200 > From: Eli Zaretskii > Cc: mbork@mbork.pl, 18236@debbugs.gnu.org > > > Date: Wed, 17 Feb 2016 19:59:02 +0000 > > From: Reuben Thomas > > Cc: Marcin Borkowski , 18236@debbugs.gnu.org > > > > Is the recipe > > ​ ​ > > complete? > > > > ​Seems so.​ > > > > > > Also, does this happen on a Posix host or on a Windows box? > > > > > > ​On a GNU/Linux system.​ > > > > > > If the former, I won't expect each line in the patch file to end with > > a ^M, only the lines that came from the files being diffed. > > > > > > Sorry, I was imprecise. ​You're quite right, only the lines that come from the files being diffed end in ^M.​ > > > > However, the original problem ​remains, as stated: after applying the patch hunk, the patched lines of the > > resultant file "bar" end \r\r\n. > > Doesn't happen on Windows. I will try on GNU/Linux and see what I > find there. I see the problem, but I don't see how this could be solved, in general. This problem will always happen when the patch file and the file to be patched are visited in Emacs using different values of buffer-file-coding-system. The problem is not limited to the EOL format, it can also happen with the text encoding, e.g. if the patch file is visited using raw-text and the file to be patched uses Latin-1 or some such. In the case in point, the patch file is visited using the -unix EOL, whereas the file to be patched is visited using -dos. If you force Emacs to visit the patch file using -dos, e.g. by using "C-x RET c dos RET C-x C-f", then the problem goes away. I don't see how we can solve this. We cannot assume that the ^M characters in the patch file's buffer should be omitted, because they could really belong to the hunk. The Patch utility does TRT in this case because it effectively reads the files as bytes. The equivalent in Emacs is to visit the files with no-conversion, but if we do that, the patched file will be displayed to the user without decoding, which is not good. The most we can do is display a warning and ask for confirmation when the values of buffer-file-coding-system differ between the patch file's buffer and the buffer of file to be patched. Will that be sufficient?