GNU bug report logs -
#65049
29.1; vc-do-command fails in windows emacs 29.1
Previous Next
Reported by: Maxim Kim <habamax <at> gmail.com>
Date: Fri, 4 Aug 2023 07:51:01 UTC
Severity: normal
Found in version 29.1
Done: Dmitry Gutov <dmitry <at> gutov.dev>
Bug is archived. No further changes may be made.
Full log
Message #110 received at 65049 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 27 Aug 2023 04:14:11 +0300
> Cc: juri <at> linkov.net, habamax <at> gmail.com, 65049 <at> debbugs.gnu.org
> From: Dmitry Gutov <dmitry <at> 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.
This bug report was last modified 231 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.