[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65049: Minor update to the repro steps
From: |
Eli Zaretskii |
Subject: |
bug#65049: Minor update to the repro steps |
Date: |
Sun, 27 Aug 2023 08:36:04 +0300 |
> 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.
- bug#65049: Minor update to the repro steps, (continued)
- bug#65049: Minor update to the repro steps, Eli Zaretskii, 2023/08/23
- bug#65049: Minor update to the repro steps, Dmitry Gutov, 2023/08/23
- bug#65049: Minor update to the repro steps, Eli Zaretskii, 2023/08/24
- bug#65049: Minor update to the repro steps, Dmitry Gutov, 2023/08/24
- bug#65049: Minor update to the repro steps, Dmitry Gutov, 2023/08/24
- bug#65049: Minor update to the repro steps, Dmitry Gutov, 2023/08/24
- bug#65049: Minor update to the repro steps, Eli Zaretskii, 2023/08/25
- bug#65049: Minor update to the repro steps, Dmitry Gutov, 2023/08/25
- bug#65049: Minor update to the repro steps, Eli Zaretskii, 2023/08/26
- bug#65049: Minor update to the repro steps, Dmitry Gutov, 2023/08/26
- bug#65049: Minor update to the repro steps,
Eli Zaretskii <=
- bug#65049: Minor update to the repro steps, Dmitry Gutov, 2023/08/27
- bug#65049: Minor update to the repro steps, Eli Zaretskii, 2023/08/28
- bug#65049: Minor update to the repro steps, Dmitry Gutov, 2023/08/28
- bug#65049: Minor update to the repro steps, Eli Zaretskii, 2023/08/28
- bug#65049: Minor update to the repro steps, Dmitry Gutov, 2023/08/28
- bug#65049: Minor update to the repro steps, Eli Zaretskii, 2023/08/28
- bug#65049: Minor update to the repro steps, Dmitry Gutov, 2023/08/28
- bug#65049: Minor update to the repro steps, Eli Zaretskii, 2023/08/28
- bug#65049: Minor update to the repro steps, Richard Stallman, 2023/08/30
- bug#65049: Minor update to the repro steps, Dmitry Gutov, 2023/08/30