Variable for Confirming Killing a Buffer

Variable for Confirming Killing a Buffer

[Oliver Taylor]

Emacs asks for confirmation when killing modified file-visiting buffers, but
does not do so for non-file-visiting buffers.

The option `buffer-offer-save' tells Emacs to prompt to you save modified
non-file-visiting buffers when EXITING Emacs, but no such option exists for
killing buffers (as described in the docstring for `buffer-offer-save').

I’ve wanted this feature for a while, and managed to create a working solution
with this:

--------------------------------
(defvar-local buffer-confirm-kill nil
 "Non-nil means confirm killing buffer when modified.
Variable is checked by `buffer-confirm-kill-p'.")

(defun buffer-confirm-kill-p ()
 "Return nil if buffer is modified and `buffer-confirm-kill' is t.
This function is designed to be called from `kill-buffer-query-functions'."
 (if (and (buffer-modified-p)
          buffer-confirm-kill)
     (yes-or-no-p
      (format "Buffer %S is modified; kill anyway? " (buffer-name)))
   t))

(add-hook 'kill-buffer-query-functions #'buffer-confirm-kill-p)
--------------------------------

Now, doing (setq-local buffer-confirm-kill t) will prevent accidental data
loss.

It’s been so useful that I wonder if something like this shouldn’t just be
part of Emacs itself.

I just had a new baby so I can’t promise to keep up with responses to this
thread, but I wanted to post a first draft of this now, both to get feedback
on the idea, and to enable anyone who might have the urge to run with the
idea. I’d love to turn it into a proper submission myself, but I might have to
wait until I’m sleeping through the night!

Re: Variable for Confirming Killing a Buffer

[Stefan Kangas]

Oliver Taylor <olivertaylor@me.com> writes:

> Now, doing (setq-local buffer-confirm-kill t) will prevent accidental data
> loss.

Could you describe the scenario(s) under which you have experienced
accidental data loss in more detail?  Which modes were you using?

> I just had a new baby so I can’t promise to keep up with responses to this
> thread,

Congratulations!  Sounds like you'll have no trouble staying busy.  :-)

Re: Variable for Confirming Killing a Buffer

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> Oliver Taylor <olivertaylor@me.com> writes:
>
>> Now, doing (setq-local buffer-confirm-kill t) will prevent accidental data
>> loss.
>
> Could you describe the scenario(s) under which you have experienced
> accidental data loss in more detail?  Which modes were you using?

A common example I can imagine lot of people have experienced is the
accidental killing of the *scratch* buffer.

-- 
	Philip Kaludercic

Re: Variable for Confirming Killing a Buffer

[Oliver Taylor]

> On Dec 2, 2021, at 2:41 PM, Stefan Kangas <stefankangas@gmail.com> wrote:
> 
> Oliver Taylor <olivertaylor@me.com> writes:
> 
>> Now, doing (setq-local buffer-confirm-kill t) will prevent accidental data
>> loss.
> 
> Could you describe the scenario(s) under which you have experienced
> accidental data loss in more detail?  Which modes were you using?

I create new buffers all the time to cleanup text from outside Emacs, or simply as an easy way to quickly jot something down. Those buffers are easy to forget about and lose if you quit Emacs without remembering to save them.

There are also a number of scratch buffer packages which also might benefit from this. 

Re: Variable for Confirming Killing a Buffer

[Lars Ingebrigtsen]

Oliver Taylor <olivertaylor@me.com> writes:

> (add-hook 'kill-buffer-query-functions #'buffer-confirm-kill-p)

I'm not sure this is the best way to achieve this -- and it'll get in
the way of some things that create buffers and then expect to be able to
kill them off without any queries, I think.

Perhaps we should instead bind `C-x k' to a new command that calls
kill-buffer after (possibly) querying the user instead.

As for the feature itself, I expect people to want to be able to kill
some buffers without query, anyway, so perhaps it should allow a list of
major modes that should be queried?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Variable for Confirming Killing a Buffer

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> As for the feature itself, I expect people to want to be able to kill
> some buffers without query, anyway, so perhaps it should allow a list
> of major modes that should be queried?

This reminds me of emacs-lock.el.  Maybe that package could be improved
where necessary?

Michael.

Re: Variable for Confirming Killing a Buffer

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> This reminds me of emacs-lock.el.  Maybe that package could be improved
> where necessary?

Ah, I didn't know about that package at all.  Reading the doc strings,
it seems like it does everything discussed here (and more):

;; This package defines a minor mode Emacs Lock to mark a buffer as
;; protected against accidental killing, or exiting Emacs, or both.
;; Buffers associated with inferior modes, like shell or telnet, can
;; be treated specially, by auto-unlocking them if their inferior
;; processes are dead.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Variable for Confirming Killing a Buffer

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Ah, I didn't know about that package at all.  Reading the doc strings,
> it seems like it does everything discussed here (and more): [...]

Yes.  AFAIK, it doesn't offer an `ask' like option, one has to remove
the lock of a locked buffer explicitly to kill it.  But removing the
lock is not harder than saying "yes" to a prompt.

A kind of "soft" lock that just causes a confirmation prompt could be
added, dunno if that would be more popular.  I don't use the package
regularly since I switched to master (Emacs doesn't cancel crashing when
it sees a lock).

Michael.

Re: Variable for Confirming Killing a Buffer

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> I don't use the package regularly since I switched to master (Emacs
> doesn't cancel crashing when it sees a lock).

We really should work on implementing that, then.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Variable for Confirming Killing a Buffer

[Oliver Taylor]

> On Dec 3, 2021, at 8:58 AM, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> 
>> (add-hook 'kill-buffer-query-functions #'buffer-confirm-kill-p)
> 
> I'm not sure this is the best way to achieve this -- and it'll get in
> the way of some things that create buffers and then expect to be able to
> kill them off without any queries, I think.

Yes, I would expect that there’s a better way to do this. But as-is this doesn’t get in the way simply because it requires the buffer-local variable to be explicitly set.

> Perhaps we should instead bind `C-x k' to a new command that calls
> kill-buffer after (possibly) querying the user instead.

I would imagine the flaw with this is that there are probably a lot of different ways buffers get killed, and a key binding is only one of them, so it would only offer a little protection.

> As for the feature itself, I expect people to want to be able to kill
> some buffers without query, anyway, so perhaps it should allow a list of
> major modes that should be queried?

Would this be better accomplished by setting the variable via a mode-hook?

Re: Variable for Confirming Killing a Buffer

[Lars Ingebrigtsen]

Oliver Taylor <olivertaylor@me.com> writes:

> I would imagine the flaw with this is that there are probably a lot of
> different ways buffers get killed, and a key binding is only one of
> them, so it would only offer a little protection.

I think it's the explicit user-initiated kills that we'd want to be able
to stop, though?  Whether (say) man-mode has decided to kill off a
buffer it's created isn't very interesting for the users.

>> As for the feature itself, I expect people to want to be able to kill
>> some buffers without query, anyway, so perhaps it should allow a list of
>> major modes that should be queried?
>
> Would this be better accomplished by setting the variable via a mode-hook?

Perhaps?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no