bug#15746: 24.3; [PATCH] bookmark should confirm when overwrite

[Karl Fogel <kfogel@red-bean.com>]

Leo Liu <sdl.web@gmail.com> writes:
>Occationally I have overwritten bookmarks with regrets. So maybe
>something along the following lines is needed.
>
>=== modified file 'lisp/bookmark.el'
>--- lisp/bookmark.el	2013-09-11 03:31:56 +0000
>+++ lisp/bookmark.el	2013-10-29 03:27:15 +0000
>@@ -811,6 +811,12 @@
>                      bookmark-minibuffer-read-name-map
>                      nil nil defaults))))
>            (and (string-equal str "") (setq str default))
>+           (when (and (not no-overwrite)
>+                      (bookmark-get-bookmark str)
>+                      (called-interactively-p 'interactive)
>+                      (not (yes-or-no-p
>+                            (format "Bookmark `%s' exists; overwrite? " str))))
>+             (user-error "Aborted"))
>            (bookmark-store str (cdr record) no-overwrite)
> 
>            ;; Ask for an annotation buffer for this bookmark

This is interesting.  I saw Drew's followup; there are good arguments on
both sides, but on balance I think Leo's general idea is right.

I think most users would expect that that *interactively* setting a
bookmark would confirm when overriding a previous bookmark of the same
name, instead of just silently overwriting it.

Drew might be right that `bookmark-set' should not include this
functionality itself, but then there should be a wrapper function, and
every interactive key (C-x r m) currently default bound to
`bookmark-set' should be instead set to that wrapper function, then.
IOW, that question is just a matter of internal code orgainzation, not
of user-visible functionality.

(I'm tempted to just build the check directly into `bookmark-set' as Leo
does, though, because people already have custom bindings for that, and
anyway, testing `call-interactively' is enough -- it leaves
`bookmark-set's programmatic functionality unchanged.)

Leo, there would need to be a patch to the doc string too, but I can
write that.  I would probably also change the `user-error' behavior
along the lines Drew suggested.

First, I'd like to know if anyone else has thoughts on the overall
behavior...?

-Karl