bug#13705: 24.2.93; "^M" characters in diff buffers

[Eli Zaretskii]

> Date: Wed, 13 Feb 2013 19:59:23 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 13705-done@debbugs.gnu.org
> 
> >   (let ((coding-system-for-read 'no-conversion))
> >     (call-process shell-file-name nil t nil
> >                   shell-command-switch "diff -c fa fb"))
> >
> > and look at the lines generated by Diff, like these:
> >
> >  *** fa 2013-02-12 18:41:03.201375000 +0200
> >  --- fb 2013-02-08 16:25:03.161000000 +0200
> 
> The above expression produces the output shown in
> "Screenshot-MS-Windows.png" (attached).

As expected.

> Yes, the problem seems to be the one you've spotted, but note that
> I've just reproduced the exact same problem on Ubuntu [1].  See the
> screenshot "Screenshot-Ubuntu.png" (attached).

On Ubuntu, it is expected to see the ^M characters, because that's
what you'd see if you invoke Diff from the shell prompt as well.

IOW, on Windows, two files which have DOS EOLs should not show ^M in
the Diff output, because DOS EOLs are native on Windows, and ^M at the
end of the line is not considered part of the text there.  On Unix,
files with DOS EOLs are expected to be seen with the ^M explicit,
because it _is_ part of the text.

> Therefore, the problem seems to be more general: it affects to every
> diff made from two files with DOS-type EOLs, unless the "diff" program
> is adapted to deal with this scenario (like the one from GnuWin32).

It _is_ general, but it is not a problem.  When Emacs sees
inconsistent EOL format it _always_ refrains from decoding the EOLs.