GNU bug report logs - #3348
23.0.92.1; Ediff: Creating a multi-file patch

Previous Next

Full log

Message #20 received at 3348 <at> debbugs.gnu.org (full text, mbox):

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: 3348 <at> debbugs.gnu.org
Cc: jstrait <at> moonloop.net, Noam Postavsky <npostavs <at> users.sourceforge.net>
Subject: Re: bug#3348: 23.0.92.1; Ediff: Creating a multi-file patch
Date: Sat, 1 Mar 2025 08:02:57 -0300

[Message part 1 (text/plain, inline)]

Mauro Aranda <maurooaranda <at> gmail.com> writes:

> Noam Postavsky <npostavs <at> users.sourceforge.net> writes:
>
>> tag 3348 + confirmed
>> severity 3348 minor
>> found 3348 25.0.94
>> quit
>>
>> Confirmed this is still an issue. Here is an elisp script for easier
>> reproduction (run as emacs -Q -l bug-3348.el):
>>
>> (defconst bug-3348-test-dir
>>   (expand-file-name "bug-3348-testdir" temporary-file-directory))
>> (make-directory bug-3348-test-dir t)
>> (cd bug-3348-test-dir)
>>
>> (make-directory "dir-a" t)
>> (make-directory "dir-b" t)
>>
>> (with-temp-file "dir-a/file"
>>   (insert "aaa"))
>> (with-temp-file "dir-b/file"
>>   (insert "bbb"))
>>
>> (ediff-directories "dir-a" "dir-b" nil)
>> (switch-to-buffer "*Ediff Session Group Panel*")
>>
>> (ediff-next-meta-item 1)
>> (ediff-mark-for-operation-at-pos nil)
>> (ediff-collect-custom-diffs)
>>
>> (with-current-buffer "*Ediff Multifile Diffs*"
>>   (write-file "foo.patch"))
>>
>> (with-temp-file "dir-b/file"
>>   (insert "BBB"))
>>
>> (ediff-collect-custom-diffs)
>>
>> (switch-to-buffer "foo.patch")
>> (diff-buffer-with-file)
>> (message (concat "Observe foo.patch buffer is different from its 
file,\n"
>>                  "but is marked read-only, not modified"))
>
> This still happens, but I'm not really sure if this should be called a
> bug.  ediff-collect-custom-diffs explicitly marks this buffer as not
> modified with (set-buffer-modified-p nil).  I can't find the reasons for
> that, but that doesn't mean there isn't a good one.  And it is
> consistent about doing that.
>
> The first call to ediff-collect-custom-diffs creates the buffer
> *Ediff Multifile Diffs* and also marks it as unmodified, even though it
> is.  So, why is that not a problem? Why is the second time a problem?
>
> Using write-file again is possible, so what are the expectations of the
> second time of typing `P' (or calling ediff-collect-custom-diffs) and
> why do they differ from the expectations for the 1st call?

After a year and a half, I think I got it :-)

After the call to write-file, ediff-meta-diff-buffer is visting a file,
and ediff assumes it never visits a file: that's why it erases, refills
it, and marks it as not modified.

So I think the attached patch fixes it.

[0001-Guard-against-user-saving-ediff-meta-diff-buffer.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.