unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Dmitry Gutov <dmitry@gutov.dev>
Cc: 65049@debbugs.gnu.org, habamax@gmail.com, juri@linkov.net
Subject: bug#65049: Minor update to the repro steps
Date: Mon, 28 Aug 2023 19:57:38 +0300	[thread overview]
Message-ID: <838r9vhzp9.fsf@gnu.org> (raw)
In-Reply-To: <c0529a33-e186-7080-b3a7-49ef50244b37@gutov.dev> (message from Dmitry Gutov on Mon, 28 Aug 2023 19:51:25 +0300)

> Date: Mon, 28 Aug 2023 19:51:25 +0300
> Cc: juri@linkov.net, habamax@gmail.com, 65049@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 28/08/2023 19:12, Eli Zaretskii wrote:
> >> Date: Mon, 28 Aug 2023 16:45:23 +0300
> >> Cc:juri@linkov.net,habamax@gmail.com,65049@debbugs.gnu.org
> >> From: Dmitry Gutov<dmitry@gutov.dev>
> >>
> >> On 28/08/2023 15:12, Eli Zaretskii wrote:
> >>>> Try edebug-instrumenting vc-diff-internal and then calling vc-root-diff
> >>>> anywhere (C-x v D). When the execution reaches the line that we have
> >>>> been discussing, you'll see that (vc-coding-system-for-diff (car files))
> >>>> evaluates to 'undecided because (car files) is a directory.
> >>>>
> >>>> So this mechanism is always unused in vc-root-diff.
> >>> OK, but in that case 'undecided' is the best guess we can come up
> >>> with.  It basically lets Emacs guess when it actually sees the stuff
> >>> in the diffs, while reading it into a buffer.
> >> Yes, and if it's good enough for the (possibly?) most-frequently used
> >> out of the vc-*-diff commands, then perhaps we don't need the additional
> >> detection logic?
> >>
> >> Since its introduction 30 years ago indeed the situation has changed a
> >> lot, with UTF-8 and its ubiquity. Removing the extra complication would
> >> make code a little easier to read, and reduce variability when
> >> reproducing problems. But there's no hurry, of course.
> > I'm not sure I understand which part do you want to remove.
> 
> The part that currently looks like this:
> 
> 	 (coding-system-for-read
>            ;; Force the EOL conversion to be -unix, in case the files
>            ;; to be compared have DOS EOLs.  In that case, EOL
>            ;; conversion will produce a patch file that will either
>            ;; fail to apply, or will change the EOL format of some of
>            ;; the lines in the patched file.
>            (coding-system-change-eol-conversion
> 	   (if files (vc-coding-system-for-diff (car files)) 'undecided)
>             'unix))
> 
> As we've established, the only part that's used in vc-root-diff (and 
> only now) is binding coding-system-change-eol-conversion to 
> 'undecided-unix'. We could leave it there, though it doesn't seem to 
> change the behavior in my tests.

Remove that?  What will happen to non-vc-root-diff clients of that?

Or do you mean remove the vc-coding-system-for-diff call, and use
undecided-unix instead?

If the latter, then it is sub-optimal when vc-coding-system-for-diff
does produce non-undecided value for some reason.





  reply	other threads:[~2023-08-28 16:57 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-04  7:50 bug#65049: 29.1; vc-do-command fails in windows emacs 29.1 Maxim Kim
2023-08-04  8:02 ` bug#65049: Minor update to the repro steps Maxim Kim
2023-08-04 11:05   ` Eli Zaretskii
2023-08-04 11:24     ` Maxim Kim
2023-08-04 17:56     ` Juri Linkov
2023-08-06 23:04       ` Maxim Kim
2023-08-07  1:09     ` Maxim Kim
2023-08-07 16:24       ` Eli Zaretskii
2023-08-07 23:17         ` Maxim Kim
2023-08-20 16:49         ` Juri Linkov
2023-08-20 18:25           ` Eli Zaretskii
2023-08-21  6:53             ` Juri Linkov
2023-08-21 11:00               ` Eli Zaretskii
2023-08-21 11:39                 ` Maxim Kim
2023-08-21 12:18                   ` Eli Zaretskii
2023-08-21 23:10             ` Maxim Kim
2023-08-22 12:52               ` Eli Zaretskii
2023-08-22 13:12                 ` Maxim Kim
2023-08-22 13:17                   ` Eli Zaretskii
2023-08-22 23:43                     ` Maxim Kim
2023-08-23  4:28                     ` Maxim Kim
2023-08-23 16:21                       ` Eli Zaretskii
2023-08-23 17:42                         ` Juri Linkov
2023-08-23 18:43                           ` Eli Zaretskii
2023-08-23 20:13                         ` Dmitry Gutov
2023-08-24  4:54                           ` Eli Zaretskii
2023-08-24 21:06                             ` Dmitry Gutov
2023-08-24 21:35                               ` Dmitry Gutov
2023-08-24 21:44                                 ` Dmitry Gutov
2023-08-25  6:18                                   ` Eli Zaretskii
2023-08-26  0:45                                     ` Dmitry Gutov
2023-08-26  8:50                                       ` Eli Zaretskii
2023-08-27  1:14                                         ` Dmitry Gutov
2023-08-27  5:36                                           ` Eli Zaretskii
2023-08-27 22:32                                             ` Dmitry Gutov
2023-08-28 12:12                                               ` Eli Zaretskii
2023-08-28 13:45                                                 ` Dmitry Gutov
2023-08-28 16:12                                                   ` Eli Zaretskii
2023-08-28 16:51                                                     ` Dmitry Gutov
2023-08-28 16:57                                                       ` Eli Zaretskii [this message]
2023-08-28 17:39                                                         ` Dmitry Gutov
2023-08-28 18:26                                                           ` Eli Zaretskii
2023-08-31  2:07                                                             ` Richard Stallman
2023-08-31  2:14                                                               ` Dmitry Gutov
2023-08-31  6:00                                                                 ` Eli Zaretskii
2023-08-23 23:46                         ` Maxim Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=838r9vhzp9.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=65049@debbugs.gnu.org \
    --cc=dmitry@gutov.dev \
    --cc=habamax@gmail.com \
    --cc=juri@linkov.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).