[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: kill-matching-buffers without confirmation
From: |
Clément Pit-Claudel |
Subject: |
Re: kill-matching-buffers without confirmation |
Date: |
Mon, 22 May 2017 15:13:15 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 |
On 2017-05-22 15:00, Kaushal Modi wrote:
> A defcustom seems too risky for this. A user can unknowingly copy that var
> from somewhere and then end up killing modified buffers without confirmation.
I don't think we've applied such a standard before: we have multiple other
variables that disable confirmation prompts, like
confirm-nonexistent-file-or-buffer, confirm-kill-processes or
kill-buffer-query-functions.
> Add a new defun that just sets the new optional arg to non-nil value is less
> risky as the user would then be knowingly calling the risky variant.
Isn't there a similar risk of a user unknowingly copying code that rebinds the
default binding to the risky variant?
Cheers,
Clément.
- kill-matching-buffers without confirmation, R. Diez, 2017/05/22
- Re: kill-matching-buffers without confirmation, Kaushal Modi, 2017/05/22
- Re: kill-matching-buffers without confirmation, Clément Pit-Claudel, 2017/05/22
- Re: kill-matching-buffers without confirmation, Kaushal Modi, 2017/05/22
- Re: kill-matching-buffers without confirmation, Clément Pit-Claudel, 2017/05/22
- Re: kill-matching-buffers without confirmation, Kaushal Modi, 2017/05/22
- Re: kill-matching-buffers without confirmation,
Clément Pit-Claudel <=
- Re: kill-matching-buffers without confirmation, Kaushal Modi, 2017/05/22
- Re: kill-matching-buffers without confirmation, Stefan Monnier, 2017/05/22
RE: kill-matching-buffers without confirmation, Drew Adams, 2017/05/22
Re: kill-matching-buffers without confirmation, R. Diez, 2017/05/23