* bug#18236: diff-apply-hunk interacts poorly with line endings @ 2014-08-10 15:34 Reuben Thomas 2016-02-17 15:35 ` Marcin Borkowski 0 siblings, 1 reply; 10+ messages in thread From: Reuben Thomas @ 2014-08-10 15:34 UTC (permalink / raw) To: 18236 [-- Attachment #1: Type: text/plain, Size: 696 bytes --] I'm using Emacs 24.3. Consider the following two files: foo: ----cut here---- This is a small test file. It has DOS line endings. ----cut here---- bar: ----cut here---- This is a small test file. It too has DOS line endings. ----cut here---- Save them with DOS line endings, and diff foo bar > foo.patch cp foo bar Visit foo.patch. When I do that, each line ends in ^M. Now, in the patch buffer, M-x diff-apply-hunk. Note that the ^Ms have been added to the lines. Writing the buffer and examination with "hd" reveals that each line now ends \r\r\n. It seems what's happened here is that diff-mode doesn't try to diagnose the character encoding of the patch file. -- http://rrt.sc3d.org [-- Attachment #2: Type: text/html, Size: 1082 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#18236: diff-apply-hunk interacts poorly with line endings 2014-08-10 15:34 bug#18236: diff-apply-hunk interacts poorly with line endings Reuben Thomas @ 2016-02-17 15:35 ` Marcin Borkowski 2016-02-17 16:39 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Marcin Borkowski @ 2016-02-17 15:35 UTC (permalink / raw) To: Reuben Thomas; +Cc: 18236 On 2014-08-10, at 17:34, Reuben Thomas <rrt@sc3d.org> wrote: > I'm using Emacs 24.3. Consider the following two files: > > foo: > ----cut here---- > This is a small test file. > It has DOS line endings. > ----cut here---- > > bar: > ----cut here---- > This is a small test file. > It too has DOS line endings. > ----cut here---- > > Save them with DOS line endings, and > > diff foo bar > foo.patch > cp foo bar > > Visit foo.patch. When I do that, each line ends in ^M. > > Now, in the patch buffer, M-x diff-apply-hunk. Note that the ^Ms have been added to the lines. Writing the buffer and examination with "hd" reveals that each line now ends > \r\r\n. > > It seems what's happened here is that diff-mode doesn't try to diagnose the character encoding of the patch file. Hi all, confirmed on GNU Emacs 25.1.50.2 (commit 4ccd268). Best, -- Marcin Borkowski ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#18236: diff-apply-hunk interacts poorly with line endings 2016-02-17 15:35 ` Marcin Borkowski @ 2016-02-17 16:39 ` Eli Zaretskii 2016-02-17 19:59 ` Reuben Thomas 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2016-02-17 16:39 UTC (permalink / raw) To: Marcin Borkowski; +Cc: rrt, 18236 > From: Marcin Borkowski <mbork@mbork.pl> > Date: Wed, 17 Feb 2016 16:35:04 +0100 > Cc: 18236@debbugs.gnu.org > > On 2014-08-10, at 17:34, Reuben Thomas <rrt@sc3d.org> wrote: > > > I'm using Emacs 24.3. Consider the following two files: > > > > foo: > > ----cut here---- > > This is a small test file. > > It has DOS line endings. > > ----cut here---- > > > > bar: > > ----cut here---- > > This is a small test file. > > It too has DOS line endings. > > ----cut here---- > > > > Save them with DOS line endings, and > > > > diff foo bar > foo.patch > > cp foo bar > > > > Visit foo.patch. When I do that, each line ends in ^M. > > > > Now, in the patch buffer, M-x diff-apply-hunk. Note that the ^Ms have been added to the lines. Writing the buffer and examination with "hd" reveals that each line now ends > > \r\r\n. > > > > It seems what's happened here is that diff-mode doesn't try to diagnose the character encoding of the patch file. > > Hi all, > > confirmed on GNU Emacs 25.1.50.2 (commit 4ccd268). When I try doing that, I get an error message. Is the recipe complete? Also, does this happen on a Posix host or on a Windows box? 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. I'm confused. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#18236: diff-apply-hunk interacts poorly with line endings 2016-02-17 16:39 ` Eli Zaretskii @ 2016-02-17 19:59 ` Reuben Thomas 2016-02-17 20:14 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Reuben Thomas @ 2016-02-17 19:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Marcin Borkowski, 18236 [-- Attachment #1: Type: text/plain, Size: 1929 bytes --] On 17 February 2016 at 16:39, Eli Zaretskii <eliz@gnu.org> wrote: > > From: Marcin Borkowski <mbork@mbork.pl> > > Date: Wed, 17 Feb 2016 16:35:04 +0100 > > Cc: 18236@debbugs.gnu.org > > > > On 2014-08-10, at 17:34, Reuben Thomas <rrt@sc3d.org> wrote: > > > > > I'm using Emacs 24.3. Consider the following two files: > > > > > > foo: > > > ----cut here---- > > > This is a small test file. > > > It has DOS line endings. > > > ----cut here---- > > > > > > bar: > > > ----cut here---- > > > This is a small test file. > > > It too has DOS line endings. > > > ----cut here---- > > > > > > Save them with DOS line endings, and > > > > > > diff foo bar > foo.patch > > > cp foo bar > > > > > > Visit foo.patch. When I do that, each line ends in ^M. > > > > > > Now, in the patch buffer, M-x diff-apply-hunk. Note that the ^Ms have > been added to the lines. Writing the buffer and examination with "hd" > reveals that each line now ends > > > \r\r\n. > > > > > > It seems what's happened here is that diff-mode doesn't try to > diagnose the character encoding of the patch file. > > > > Hi all, > > > > confirmed on GNU Emacs 25.1.50.2 (commit 4ccd268). > > When I try doing that, I get an error message. I just repeated the recipe, now in Emacs 24.4. It worked as described. > 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. -- http://rrt.sc3d.org [-- Attachment #2: Type: text/html, Size: 3614 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#18236: diff-apply-hunk interacts poorly with line endings 2016-02-17 19:59 ` Reuben Thomas @ 2016-02-17 20:14 ` Eli Zaretskii 2016-02-20 12:16 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2016-02-17 20:14 UTC (permalink / raw) To: Reuben Thomas; +Cc: mbork, 18236 > Date: Wed, 17 Feb 2016 19:59:02 +0000 > From: Reuben Thomas <rrt@sc3d.org> > Cc: Marcin Borkowski <mbork@mbork.pl>, 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#18236: diff-apply-hunk interacts poorly with line endings 2016-02-17 20:14 ` Eli Zaretskii @ 2016-02-20 12:16 ` Eli Zaretskii 2016-02-20 12:32 ` Reuben Thomas 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2016-02-20 12:16 UTC (permalink / raw) To: Reuben Thomas; +Cc: mbork, 18236 > Date: Wed, 17 Feb 2016 22:14:04 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: mbork@mbork.pl, 18236@debbugs.gnu.org > > > Date: Wed, 17 Feb 2016 19:59:02 +0000 > > From: Reuben Thomas <rrt@sc3d.org> > > Cc: Marcin Borkowski <mbork@mbork.pl>, 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? ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#18236: diff-apply-hunk interacts poorly with line endings 2016-02-20 12:16 ` Eli Zaretskii @ 2016-02-20 12:32 ` Reuben Thomas 2016-02-20 12:50 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Reuben Thomas @ 2016-02-20 12:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Marcin Borkowski, 18236 [-- Attachment #1: Type: text/plain, Size: 565 bytes --] On 20 February 2016 at 12:16, Eli Zaretskii <eliz@gnu.org> wrote: > > 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? > Thanks for your analysis. This solution sounds fine to me: as you say, in general it's impossible to tell exactly what went wrong, but we can warn the user so that the unfortunate result I described is not obtained silently. -- http://rrt.sc3d.org [-- Attachment #2: Type: text/html, Size: 1072 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#18236: diff-apply-hunk interacts poorly with line endings 2016-02-20 12:32 ` Reuben Thomas @ 2016-02-20 12:50 ` Eli Zaretskii 2016-02-21 10:09 ` Marcin Borkowski 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2016-02-20 12:50 UTC (permalink / raw) To: Reuben Thomas; +Cc: mbork, 18236 > Date: Sat, 20 Feb 2016 12:32:03 +0000 > From: Reuben Thomas <rrt@sc3d.org> > Cc: Marcin Borkowski <mbork@mbork.pl>, 18236@debbugs.gnu.org > > 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? > > Thanks for your analysis. This solution sounds fine to me: as you say, in general it's impossible to tell exactly > what went wrong, but we can warn the user so that the unfortunate result I described is not obtained silently. Marcin, would you like to work on a change along these lines? The function to use for comparing 2 coding-systems is `coding-system-equal'. The idea is to see if the values of `buffer-file-coding-system' in the patch-file buffer (where the command is invoked) and in the buffer that visits the file to be patched (after `find-file-noselect' call in `diff-find-source-location' returns) are different, and if so, ask the user for confirmation. Ideally, the confirmation should only be requested once, when applying the 1st hunk from the patch file. Thanks. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#18236: diff-apply-hunk interacts poorly with line endings 2016-02-20 12:50 ` Eli Zaretskii @ 2016-02-21 10:09 ` Marcin Borkowski 2016-02-21 15:56 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Marcin Borkowski @ 2016-02-21 10:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Reuben Thomas, 18236 On 2016-02-20, at 13:50, Eli Zaretskii <eliz@gnu.org> wrote: >> Date: Sat, 20 Feb 2016 12:32:03 +0000 >> From: Reuben Thomas <rrt@sc3d.org> >> Cc: Marcin Borkowski <mbork@mbork.pl>, 18236@debbugs.gnu.org >> >> 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? >> >> Thanks for your analysis. This solution sounds fine to me: as you say, in general it's impossible to tell exactly >> what went wrong, but we can warn the user so that the unfortunate result I described is not obtained silently. > > Marcin, would you like to work on a change along these lines? OK, I'll take a look and report in a few days. Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#18236: diff-apply-hunk interacts poorly with line endings 2016-02-21 10:09 ` Marcin Borkowski @ 2016-02-21 15:56 ` Eli Zaretskii 0 siblings, 0 replies; 10+ messages in thread From: Eli Zaretskii @ 2016-02-21 15:56 UTC (permalink / raw) To: Marcin Borkowski; +Cc: rrt, 18236 > From: Marcin Borkowski <mbork@mbork.pl> > Cc: Reuben Thomas <rrt@sc3d.org>, 18236@debbugs.gnu.org > Date: Sun, 21 Feb 2016 11:09:41 +0100 > > > Marcin, would you like to work on a change along these lines? > > OK, I'll take a look and report in a few days. Thanks. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-02-21 15:56 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-08-10 15:34 bug#18236: diff-apply-hunk interacts poorly with line endings Reuben Thomas 2016-02-17 15:35 ` Marcin Borkowski 2016-02-17 16:39 ` Eli Zaretskii 2016-02-17 19:59 ` Reuben Thomas 2016-02-17 20:14 ` Eli Zaretskii 2016-02-20 12:16 ` Eli Zaretskii 2016-02-20 12:32 ` Reuben Thomas 2016-02-20 12:50 ` Eli Zaretskii 2016-02-21 10:09 ` Marcin Borkowski 2016-02-21 15:56 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).