bug#65049: Minor update to the repro steps

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 27 Aug 2023 04:14:11 +0300
> Cc: juri@linkov.net, habamax@gmail.com, 65049@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 26/08/2023 11:50, Eli Zaretskii wrote:
> 
> I'm guessing that if we try hard enough with files encoded in an "alien" 
> coding system, we will see a similar difference between vc-diff and 
> vc-root-diff.

We could.  The 'undecided-unix' value is a good default, but if the
fileset includes files with different incompatible encodings, there's
no single coding-system that could satisfy that, and what Emacs
guesses will probably be okay for the first file, but not necessarily
for the rest.

> >    . When the compared files have DOS EOLs, applying the patch on Posix
> >      hosts (and with Git on all hosts) must preserve the ^M characters
> >      at ends of lines in the diffs buffer.  This might be a bit ugly
> >      when viewing the diffs, but if the same commands are used for
> >      patching, this cannot be helped.
> 
> There are two questions here: how the diff buffer should look to the 
> user, and what patch to feed to Git programmatically. If we decide that 
> the formats should be different (e.g. with/without ^M), we could 
> probably perform additional newline conversion inside the patch text too.

Yes, we could implement some display-time nicety.

> >    . In all my experience with VCSes managing repositories with mixed
> >      EOL formats (such as what we have in Emacs) on Windows, the only
> >      sane way of doing that is to force the VCS to leave the original
> >      EOLs intact.  With CVS and RCS, this is done by checking out all
> >      the text files as "binary"; in Git, there's a config setting to do
> >      that.  I have no real experience with SVN and Hg, so I don't know
> >      what happens there.  So it's possible we should remove the special
> >      handling of Windows in vc-diff-internal, because its only reason
> >      is to show "nicer" diffs.
> 
> What does it look like on Windows without the "special handling"? Not 
> displayed as a bunch of ^M, right?

Yes, the ^M are removed by EOL conversion.

> >    . The line you suggest to remove should IMO stay, because your
> >      suggestion is based on what you see with plain-ASCII files.  If
> >      the files have some non-trivial text encoding, failing to use the
> >      right encoding for the diffs will produce mojibake.  The EOL
> >      conversion produced by vc-coding-system-for-diff is indeed
> >      problematic, see above; but the text-conversion part is not, and
> >      should stay.
> > 
> > Therefore, I propose the patch below, which incorporates the above
> > change, for the emacs-29 branch.  I think it is safe to use the 'unix
> > EOL conversion on all systems, in the vc-git.el part of the changeset,
> > but if you feel uneasy about that on the release branch, we could make
> > it Windows-specific on emacs-29 and remove the condition on master.
> 
> LGTM for emacs-29, thank you. In case anybody reports a problem, we can 
> add that OS limitation later.

Thanks, installed on the emacs-29 branch.

> Regarding your paragraph above about mojibake, though. That makes a lot 
> of sense, but I feel I have to stress: this mechanism doesn't work for 
> vc-root-diff (C-x v D).

Not sure I understand.  Can you show a recipe for "doesn't work"?

> Does that mean the coding system mismatch sufferers just silently use 
> vc-diff and never report their problems with vc-root-diff? The latter 
> command was added in 2009. No contest with 1992, but still.

I think it means most source files are plain-ASCII or UTF-8 at most.