kill-buffer without asking for confirmation

kill-buffer without asking for confirmation

[Peter Münster]

Hi,

When a buffer is modified, kill-buffer normally asks for confirmation
("Buffer modified; kill anyway?"). How can I avoid this confirmation
please?

This worked with version 28.X:

(defun some-function-called-by-timer ()
  "Send email to user."
  (compose-mail user-mail-address "bla")
  (insert "bla")
  (funcall send-mail-function)
  (cl-letf (((symbol-function 'yes-or-no-p) (lambda (_) t)))
    (kill-buffer)))

But unfortunately, it doesn't work any more with the latest 29.0.50.

TIA for any help,
-- 
           Peter

Re: kill-buffer without asking for confirmation

[Tassilo Horn]

Peter Münster <pm@a16n.net> writes:

Hi Peter,

> When a buffer is modified, kill-buffer normally asks for confirmation
> ("Buffer modified; kill anyway?"). How can I avoid this confirmation
> please?
>
> This worked with version 28.X:
>
> (defun some-function-called-by-timer ()
>   "Send email to user."
>   (compose-mail user-mail-address "bla")
>   (insert "bla")
>   (funcall send-mail-function)
>   (cl-letf (((symbol-function 'yes-or-no-p) (lambda (_) t)))
>     (kill-buffer)))
>
> But unfortunately, it doesn't work any more with the latest 29.0.50.

Yeah, it's not yes-or-no-query anymore but now you can answer
yes/no/"first save and then kill".  You could use your above function
but swap yes-or-no-p with kill-buffer--possibly-save (or temporarily
redefine both to "always t"), I think.

OTOH, the definition of kill-buffer in buffer.c suggests that the query
is only performed when your function is called interactively which
shouldn't be the case when it's run from a timer as its name suggests.
Another way might be to slap a (let ((noninteractive t)) ...) around the
kill-buffer call.  Maybe that does the trick, too, and works with more
emacs versions.

Bye,
Tassilo

Re: kill-buffer without asking for confirmation

[Peter Münster]

On Mon, Nov 28 2022, Tassilo Horn wrote:

> swap yes-or-no-p with kill-buffer--possibly-save

Indeed. But it seems not very clean to me, because it depends on the
naming of such low level functions...


> which shouldn't be the case when it's run from a timer as its name
> suggests.

Indeed. Perhaps a bug?


> Another way might be to slap a (let ((noninteractive t)) ...) around
> the kill-buffer call.

It does not work. And the doc suggests, that t just means, that Emacs is
running without interactive terminal.


On Mon, Nov 28 2022, Gregory Heytings wrote:

> (set-visited-file-name nil)

Yes, that seems to be a clean solution.

Thank you both for your help!

-- 
           Peter

Re: kill-buffer without asking for confirmation

[Gregory Heytings]

>
> When a buffer is modified, kill-buffer normally asks for confirmation 
> ("Buffer modified; kill anyway?"). How can I avoid this confirmation 
> please?
>

(set-visited-file-name nil)

Re: kill-buffer without asking for confirmation

[Andreas Röhler]

(defun kill-buffer-unconditional (&optional buffer)
   "Kill buffer unconditional, kill buffer-process if existing.

Sometimes being queried sucks..."
   (interactive
    (list (current-buffer)))
   (let ((buffer (or (and (bufferp buffer) buffer)
             (get-buffer (current-buffer))))
     proc kill-buffer-query-functions)
     (if (buffer-live-p buffer)
         (progn
           (setq proc (get-buffer-process buffer))
           (and proc (kill-process proc))
           (set-buffer buffer)
           (set-buffer-modified-p 'nil)
           (kill-buffer (current-buffer)))
       (message "Can't see a buffer %s" buffer))))

Am 28.11.22 um 09:40 schrieb Peter Münster:
> Hi,
>
> When a buffer is modified, kill-buffer normally asks for confirmation
> ("Buffer modified; kill anyway?"). How can I avoid this confirmation
> please?
>
> This worked with version 28.X:
>
> (defun some-function-called-by-timer ()
>    "Send email to user."
>    (compose-mail user-mail-address "bla")
>    (insert "bla")
>    (funcall send-mail-function)
>    (cl-letf (((symbol-function 'yes-or-no-p) (lambda (_) t)))
>      (kill-buffer)))
>
> But unfortunately, it doesn't work any more with the latest 29.0.50.
>
> TIA for any help,