GNU bug report logs -
#77323
[PATCH] Allow temp buffer cleanup in ediff-current-file
Previous Next
Reported by: "Paul D. Nelson" <ultrono <at> gmail.com>
Date: Thu, 27 Mar 2025 21:55:02 UTC
Severity: normal
Tags: patch
Done: Sean Whitton <spwhitton <at> spwhitton.name>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 77323 in the body.
You can then email your comments to 77323 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77323
; Package
emacs
.
(Thu, 27 Mar 2025 21:55:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Paul D. Nelson" <ultrono <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 27 Mar 2025 21:55:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
When ediff-current-file compares a modified buffer with its saved
version, it creates a temporary "FILE=..." buffer to hold the saved
contents. Currently, this buffer persists after the Ediff session
quits, requiring manual cleanup later.
In my experience, this buffer serves no further purpose once the
comparison is done, and just clutters the buffer list. On the other
hand, I could imagine someone using it as a way to retain a snapshot of
the saved file state.
The attached patch introduces a user option that, when non-nil, causes
the "FILE=..." buffer to be killed automatically after quitting Ediff.
The default is nil, so that the patch does not modify existing behavior.
Such automatic cleanup does not seem achievable via existing Ediff
hooks.
Any feedback would be welcome.
Thanks, best,
Paul
[Message part 2 (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77323
; Package
emacs
.
(Fri, 28 Mar 2025 01:09:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 77323 <at> debbugs.gnu.org (full text, mbox):
Hello Paul,
> When ediff-current-file compares a modified buffer with its saved
> version, it creates a temporary "FILE=..." buffer to hold the saved
> contents. Currently, this buffer persists after the Ediff session
> quits, requiring manual cleanup later.
I wonder if this related to Bug#74881 whose fix makes Emacs delete
temporary Ediff files. Does your Emacs version contain the fix of this
bug?
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77323
; Package
emacs
.
(Fri, 28 Mar 2025 05:40:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 77323 <at> debbugs.gnu.org (full text, mbox):
Hi Michael,
> I wonder if this related to Bug#74881 whose fix makes Emacs delete
> temporary Ediff files. Does your Emacs version contain the fix of this
> bug?
Thanks for checking on this. Bug#74881 seems to be about deleting
temporary files (produced by vc-ediff, I think), while the present issue
is about cleaning up temporary buffers produced by ediff-current-file.
Incidentally, my version (updated yesterday) does contain this fix.
Paul
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77323
; Package
emacs
.
(Sat, 29 Mar 2025 01:07:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 77323 <at> debbugs.gnu.org (full text, mbox):
"Paul D. Nelson" <ultrono <at> gmail.com> writes:
> Thanks for checking on this. Bug#74881 seems to be about deleting
> temporary files (produced by vc-ediff, I think), while the present issue
> is about cleaning up temporary buffers produced by ediff-current-file.
> Incidentally, my version (updated yesterday) does contain this fix.
Ok, thanks. Then your proposal looks reasonable to me.
Allow two questions:
- Have you thought about checking
`ediff-current-file-cleanup-temporary-buffer' when quitting Ediff,
instead of when entering Ediff (with other words: in the lambda you add
to `ediff-quit-hook')? I think this would fit better with the expected
behavior. A user might toggle the new option when the Ediff session is
already running.
- Is this the only Ediff command that leaves such temporary buffers
behind?
TIA,
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77323
; Package
emacs
.
(Sat, 29 Mar 2025 08:30:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 77323 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> - Have you thought about checking
> `ediff-current-file-cleanup-temporary-buffer' when quitting Ediff,
> instead of when entering Ediff (with other words: in the lambda you add
> to `ediff-quit-hook')? I think this would fit better with the expected
> behavior. A user might toggle the new option when the Ediff session is
> already running.
My reasons for "checking before" (basically to allow let-binding of the
variable) were less compelling and specific than what you describe, so I
agree that "checking after" is more natural and have updated the patch
accordingly.
>
> - Is this the only Ediff command that leaves such temporary buffers
> behind?
The other Ediff commands that create buffers are:
- ediff-regions-* and ediff-windows-*. These create indirect buffers
that are cleaned up when Ediff quits (via ediff-temp-indirect-buffer).
- ediff-patch-buffer. This creates a buffer *_patched with the result
of applying a patch to buffer *. The persistence of this buffer is
intentional - it allows the user to inspect or save the result.
- ediff-patch-file. This applies a patch to a file, creating a backup
(e.g., ediff.el.orig), and leaves buffers visiting both files.
- vc-ediff and vc-version-ediff. These create buffers like
ediff.el.~c0a6429b5672f43114d7d67e268f31998723071d~, which can be
created by other VC commands (like log-view-find-revision) and are
reused across calls.
In each case, the buffers either visit files, are cleaned up, or are
explicitly intended for further use by the client or other commands.
There is also the option ediff-keep-variants, for which nil means to
ask to remove any unmodified A/B/C buffers when quitting Ediff.
[0001-Allow-temp-buffer-cleanup-in-ediff-current-file.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77323
; Package
emacs
.
(Sat, 29 Mar 2025 10:34:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 77323 <at> debbugs.gnu.org (full text, mbox):
Hello Paul,
There is also already ediff-keep-tmp-versions.
Even though some are about files and some are about buffers, I'm
concerned about these variables proliferating. It's already quite
confusing. Do you think there is any possibility of you reusing one of
the existing ones?
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77323
; Package
emacs
.
(Sat, 29 Mar 2025 12:47:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 77323 <at> debbugs.gnu.org (full text, mbox):
Hi Sean,
> There is also already ediff-keep-tmp-versions.
>
> Even though some are about files and some are about buffers, I'm
> concerned about these variables proliferating. It's already quite
> confusing. Do you think there is any possibility of you reusing one of
> the existing ones?
Let's see.
I think it would be confusing to reuse ediff-keep-tmp-versions (which
concerns temporary VC files) or ediff-keep-variants (which is anyways
hard-coded to "t" via ediff-buffers, hence in ediff-current-file).
I understand the concern about variable proliferation. Some
alternatives:
1) Make "clean-up" the default behavior for ediff-current-file.
2) Add an optional startup-hooks argument to ediff-current-file, passed
along to ediff-buffers. This would improve consistency with other Ediff
commands and allow clean-up of temporary buffers via a wrapper command:
(defun my/ediff-current-file-with-cleanup ()
(interactive)
(ediff-current-file
(list
(lambda ()
(let ((buffer-to-kill ediff-buffer-A))
(add-hook 'ediff-quit-hook
(lambda () (when (buffer-live-p buffer-to-kill)
(kill-buffer buffer-to-kill)))
nil t))))))
3) Take advantage of the "FILE=" prefix, which I don't think is used
elsewhere in Emacs:
(add-hook 'ediff-cleanup-hook
(lambda ()
(and (buffer-live-p ediff-buffer-A)
(string-prefix-p "FILE=" (buffer-name ediff-buffer-A))
(kill-buffer ediff-buffer-A))))
Having now stumbled upon solution 3), I think it's the simplest one for
my purposes, if a bit hacky. It makes my patch unnecessary, so we can
close this report.
Alternatively, if others feel that the undeleted temporary buffer
produced by ediff-current-file represents a bug/issue (e.g., as an
undesired "resource leak") rather than an alternative among preferences,
then I'd be happy to follow-up with either my original patch or one of
the other proposed alternatives.
Thanks for your feedback and best,
Paul
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77323
; Package
emacs
.
(Sun, 30 Mar 2025 01:54:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 77323 <at> debbugs.gnu.org (full text, mbox):
Hello,
Thank you for looking further.
Generally we don't worry too much about unkilled buffers.
Given that you have a solution to your original problem and there is the
problem of all these variables, I think we should close this bug, but
I'll give Michael a chance to chime in first.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77323
; Package
emacs
.
(Mon, 31 Mar 2025 03:05:03 GMT)
Full text and
rfc822 format available.
Message #29 received at 77323 <at> debbugs.gnu.org (full text, mbox):
Sean Whitton <spwhitton <at> spwhitton.name> writes:
> Given that you have a solution to your original problem and there is
> the problem of all these variables, I think we should close this bug,
> but I'll give Michael a chance to chime in first.
I'm not a heavy Ediff user, so don't take my words too seriously. In
general the whole Ediff thing is partially quite hard to configure, in
my opinion, if what you want had not been anticipated by the author(s).
This here is not the only case.
My thoughts here are: we should consider that the buffers we speak about
(containing the saved version of the file) might be useful to some
users. Maybe equally useful as other buffers we silently keep.
Apart from that, this case doesn't really fit into any other case that
handles automatically created buffers. Although -
`ediff-dispose-of-variant-according-to-user' is not only about indirect
buffers, right? We could marry this case with this existing mechanism.
Would that make some sense?
And apart from that, adding a STARTUP-HOOKS argument to
`ediff-current-file' looks acceptable to me, although it would have no
direct uses in Emacs currently. I don't like it when users are forced
to use really bad hacks to change the behavior of such cases.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77323
; Package
emacs
.
(Mon, 31 Mar 2025 07:08:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 77323 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Apart from that, this case doesn't really fit into any other case that
> handles automatically created buffers. Although -
> `ediff-dispose-of-variant-according-to-user' is not only about indirect
> buffers, right? We could marry this case with this existing mechanism.
> Would that make some sense?
Currently, ediff-dispose-of-variant-according-to-user
- kills any indirect buffers with ediff-temp-indirect-buffer non-nil
(used by region/window comparison), and
- if ediff-keep-variants is nil, asks about killing any unmodified
buffers.
It's not clear to me how best to fit modified non-file buffers (such as
the FILE=... buffer produced by ediff-current-file) into this picture.
And, as you point out, the user might wish to keep such buffers around.
> And apart from that, adding a STARTUP-HOOKS argument to
> `ediff-current-file' looks acceptable to me, although it would have no
> direct uses in Emacs currently. I don't like it when users are forced
> to use really bad hacks to change the behavior of such cases.
That indeed seems like the simplest way to allow customization that
doesn't resort to hacks or simply overwriting the function, so please
see the attached patch.
[Message part 2 (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77323
; Package
emacs
.
(Tue, 01 Apr 2025 01:37:03 GMT)
Full text and
rfc822 format available.
Message #35 received at 77323 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Mon 31 Mar 2025 at 09:07am +02, Paul D. Nelson wrote:
> That indeed seems like the simplest way to allow customization that
> doesn't resort to hacks or simply overwriting the function, so please
> see the attached patch.
This looks good to me.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77323
; Package
emacs
.
(Fri, 04 Apr 2025 11:47:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 77323 <at> debbugs.gnu.org (full text, mbox):
Sean Whitton <spwhitton <at> spwhitton.name> writes:
> > That indeed seems like the simplest way to allow customization that
> > doesn't resort to hacks or simply overwriting the function, so please
> > see the attached patch.
>
> This looks good to me.
Yes, to me, too.
Has Paul signed the Copyright papers? Those who know, please install
Paul's latest patch.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77323
; Package
emacs
.
(Fri, 04 Apr 2025 13:15:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 77323 <at> debbugs.gnu.org (full text, mbox):
> Cc: 77323 <at> debbugs.gnu.org, "Paul D. Nelson" <ultrono <at> gmail.com>
> Date: Fri, 04 Apr 2025 13:48:02 +0200
> From: Michael Heerdegen via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> Has Paul signed the Copyright papers?
Yes, he did.
Reply sent
to
Sean Whitton <spwhitton <at> spwhitton.name>
:
You have taken responsibility.
(Sat, 05 Apr 2025 01:38:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
"Paul D. Nelson" <ultrono <at> gmail.com>
:
bug acknowledged by developer.
(Sat, 05 Apr 2025 01:38:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 77323-done <at> debbugs.gnu.org (full text, mbox):
Hello,
Thanks, installed this.
--
Sean Whitton
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 03 May 2025 11:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 44 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.