| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I had to kill an Emacs session today over a prompt I could not answer. A
second agent session held the selected window while "Overwrite hiroshi.m3u?
(yes or no)" waited in another frame, so my keystrokes went to a terminal
and the minibuffer stayed empty. Losing unsaved buffers is a far worse
outcome than a mis-keyed confirm.
So cj/confirm-strong becomes cj/confirm-destructive, and instead of binding
use-short-answers to nil for a typed "yes" it reads a single y or n.
Two things I kept:
- No default. Only y and n answer, so a stray RET or space re-prompts
rather than confirming a shutdown.
- Pending input is discarded before the read. Without that the change would
have been a bad trade: read-char-choice reads the input queue, so a key
typed before the prompt painted would confirm instantly, where the old
typed-"yes" absorbed it harmlessly.
Worth being honest about what this does not fix. One keystroke does not
make a prompt reachable when focus is elsewhere, and C-g is still the
escape. It lowers the cost of the situation rather than preventing it.
Six call sites: shutdown and reboot, shred, playlist overwrite and delete,
and the two file overwrites.
|
