Subject: Re: bug#77323: [PATCH] Allow temp buffer cleanup in ediff-current-file

From: "Paul D. Nelson" <[email-masked]>
Date: Sat, 29 Mar 2025 13:46:22 +0100

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