bug#29916: 26.0.90; CRLF in diff-command output breaks smerge hunk header parsing

[Richard Copley <rcopley@gmail.com>]

On 31 December 2017 at 19:06, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Sun, 31 Dec 2017 18:33:56 +0000
>>
>> On Windows, CRLF line endings in the output of diff-command can lead to
>> an error in `smerge-refine-regions'. To reproduce, download this patch:
>>
>> https://lists.gnu.org/archive/html/emacs-devel/2017-06/txtWF9rI8yqfI.txt
>>
>> (It is an example of a perfectly ordinary patch, with Unix line endings.)
>>
>> >From 'emacs -Q', visit the patch file, do "M-x diff-mode RET", then
>> move point into the second diff hunk (in editfns.c) and type RET
>> (diff-goto-source).
>
> You mean M-RET, not RET, right?

No, with that recipe it is bound to o, <mouse-2>, RET, C-c C-c, M-o,
ESC <mouse-2>, M-RET, <menu-bar> <Diff> <Jump to Source>.

>> The minibuffer shows this error, with a literal carriage return, shown
>> here as ^M:
>>
>>   Error running timer: (error "Unexpected patch hunk header: 41a42,121^M")
>
> I cannot reproduce this.  I get "Hunk not yet applied at offset 205
> lines" and no error message.  Are your Emacs source files checked out
> with CRLF EOL format or something?

No.

> If not, where did you get the ported Diff command?

It's the (ubiquitous) gnuwin32 port of diff 2.8.7.

>> As a data point, the error doesn't happen after applying the attached
>> patch which partially reverts this commit:
>
> I suggest to use utf-8-emacs instead of emacs-mule (you _really_ don't
> want the latter).  I do agree that forcing -unix EOL when decoding the
> output of Diff is probably wrong.  Stefan?

Do you mean utf-8, with the end of line conversion left unspecified?
According to the manual (33.10.1), "'emacs-internal’ is an alias for
‘utf-8-emacs’."