GNU bug report logs - #18236
diff-apply-hunk interacts poorly with line endings

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: mbork <at> mbork.pl, 18236 <at> debbugs.gnu.org
Subject: bug#18236: diff-apply-hunk interacts poorly with line endings
Date: Sat, 20 Feb 2016 14:16:06 +0200

> Date: Wed, 17 Feb 2016 22:14:04 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: mbork <at> mbork.pl, 18236 <at> debbugs.gnu.org
> 
> > Date: Wed, 17 Feb 2016 19:59:02 +0000
> > From: Reuben Thomas <rrt <at> sc3d.org>
> > Cc: Marcin Borkowski <mbork <at> mbork.pl>, 18236 <at> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.