From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#65049: Minor update to the repro steps Date: Sun, 27 Aug 2023 08:36:04 +0300 Message-ID: <831qfpkpx7.fsf@gnu.org> References: <83y1iruky1.fsf@gnu.org> <83il9qom6k.fsf@gnu.org> <86v8dandhq.fsf@mail.linkov.net> <83bkf1woy3.fsf@gnu.org> <835y57tf23.fsf@gnu.org> <87edjvp6ev.fsf@gmail.com> <83350btdw8.fsf@gnu.org> <831qftspal.fsf@gnu.org> <35b50832-e9ca-9f57-fad6-68621d9b42e7@gutov.dev> <83pm3dqbtp.fsf@gnu.org> <789dacd3-8e62-74ad-f691-5b48cb1d678b@gutov.dev> <2f6986e7-f96b-98bd-4581-7503bb01b111@gutov.dev> <83ttsnoda5.fsf@gnu.org> <49d5e741-f97d-ae4d-f79c-ec418051d868@gutov.dev> <83v8d2kx1g.fsf@gnu.org> <8be534f8-9f03-5de6-53c8-76be0f9456fa@gutov.dev> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23275"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 65049@debbugs.gnu.org, habamax@gmail.com, juri@linkov.net To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Aug 27 07:37:15 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qa8SZ-0005rx-D0 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 27 Aug 2023 07:37:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qa8SH-0006f2-Hb; Sun, 27 Aug 2023 01:36:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qa8SG-0006eu-EU for bug-gnu-emacs@gnu.org; Sun, 27 Aug 2023 01:36:56 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qa8SG-0004Zy-6L for bug-gnu-emacs@gnu.org; Sun, 27 Aug 2023 01:36:56 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qa8SL-0004b0-Nh for bug-gnu-emacs@gnu.org; Sun, 27 Aug 2023 01:37:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Aug 2023 05:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65049 X-GNU-PR-Package: emacs Original-Received: via spool by 65049-submit@debbugs.gnu.org id=B65049.169311460517644 (code B ref 65049); Sun, 27 Aug 2023 05:37:01 +0000 Original-Received: (at 65049) by debbugs.gnu.org; 27 Aug 2023 05:36:45 +0000 Original-Received: from localhost ([127.0.0.1]:43849 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qa8S5-0004aV-3m for submit@debbugs.gnu.org; Sun, 27 Aug 2023 01:36:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47968) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qa8S2-0004aF-BJ for 65049@debbugs.gnu.org; Sun, 27 Aug 2023 01:36:43 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qa8Rr-0004ZC-2B; Sun, 27 Aug 2023 01:36:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=3BWeyJYCvo0hfX+2kHV1TtGQquFEY/X6SClI7nHu6Sk=; b=pHkfligeqh+7 q/E/l54MliGZiD9qTdsg0jgT6FlC8oTGSPdSYvsOQN+np+IgDsKugypEMoAUXBJ16NlRnZkGA28Py fsYCyXZYF8saY0S7yJmheoEZE8Z4rF4xh1dY+S88caay/bpfqBCbWylHBjCpdy6YD2IM8pxazEccH 4oapif7qXRNu/vZ76RvolvV/Ar9DDEclR6B0YS32zEaV/AfoA6jIbSgd6d578ircK28HNFCmmc4Uq q8j1IPYM9LjBNrJDhGnl7fIy22PBOwvFWIU8h79wcHr6HtrjnNmKh+PuXEo9cG2lcF838yNuUx4eI VsehaHrO5D/z/Vg1DvGRkg==; In-Reply-To: <8be534f8-9f03-5de6-53c8-76be0f9456fa@gutov.dev> (message from Dmitry Gutov on Sun, 27 Aug 2023 04:14:11 +0300) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:268530 Archived-At: > Date: Sun, 27 Aug 2023 04:14:11 +0300 > Cc: juri@linkov.net, habamax@gmail.com, 65049@debbugs.gnu.org > From: Dmitry Gutov > > 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.