<feed xmlns='http://www.w3.org/2005/Atom'>
<title>dotemacs/tests/test-custom-buffer-file--destructive-confirms.el, branch main</title>
<subtitle>My Emacs configuration
</subtitle>
<id>https://git.cjennings.net/dotemacs/atom?h=main</id>
<link rel='self' href='https://git.cjennings.net/dotemacs/atom?h=main'/>
<link rel='alternate' type='text/html' href='https://git.cjennings.net/dotemacs/'/>
<updated>2026-07-02T02:14:07+00:00</updated>
<entry>
<title>feat(buffer-file): confirmation policy for the destructive C-; b operations</title>
<updated>2026-07-02T02:14:07+00:00</updated>
<author>
<name>Craig Jennings</name>
<email>c@cjennings.net</email>
</author>
<published>2026-07-02T02:14:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.cjennings.net/dotemacs/commit/?id=e18cf02e22049ad3cc4ce96059edc37a5ecb6719'/>
<id>urn:sha1:e18cf02e22049ad3cc4ce96059edc37a5ecb6719</id>
<content type='text'>
Delete file (D) ran with no confirmation at all; erase, clear-to-top/bottom, and revert were a single keystroke from destroying unsaved edits; and raw revert-buffer prompted even when there was nothing to lose. Policy now: delete always confirms, naming the file (the VC path keeps vc-delete-file's own prompt); erase/clear/revert confirm only when a file-visiting buffer has unsaved edits, and stay fast otherwise. The delete workhorse is split into an unconfirmed internal so its existing tests keep exercising the file mechanics; 13 new tests cover the policy.
</content>
</entry>
</feed>
