Subject: bug#75949: kill-buffer-quit-windows breaks kill-buffer-hook

From: Juri Linkov <[email-masked]>
Date: Sat, 01 Feb 2025 19:25:47 +0200

close 75949 31.0.50
thanks

>> Then observe in the *Messages* buffer that the hook 'kill-buffer-hook'
>> is run in the *scratch* buffer that is never killed.
>>
>> Afterwards try to set kill-buffer-quit-windows back to the default value nil,
>> and evaluate again.  Then everything is correct.
>>
>> It seems that kill-buffer-quit-windows somehow messes up the current buffer
>> while running 'kill-buffer-hook'.
>
> I checked in a fix.

Thanks, I confirm there is no problem anymore.

> In general, no function on 'kill-buffer-hook' can be sure
> that the buffer to be killed is current because another function
> on that hook might have changed the current buffer (or even killed it)
> before.  That promise, like similar ones in
> 'window-configuration-change-hook', should never have been made.
>
> An appropriate fix could be possibly made in run_hook_with_args.  But
> that might change behaviors that rely on hook-2 running after hook-1
> changed the current buffer.  Ideally, we'd have 'kill-buffer-functions'
> with the buffer to be killed as sole argument (and the function on the
> hook would still have to check whether that buffer is alive).

Since a new argument can't be added, another variant would be at least
to set the current buffer before every call of the hook functions.
I.e. instead of

  (run-hooks 'kill-buffer-hook)

to do something like

  (run-hook-wrapped 'kill-buffer-hook
                    (lambda (fun)
                      (with-current-buffer current-buffer
                        (funcall fun))
                      nil))

But this won't help when buffers are switched inside hook functions.