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

[Drew Adams]

> >There are plenty of use cases where you want to silently *update* an
> >existing bookmark, e.g., update its location.
>
> There are definitely cases where one wants to update; that one wants
> to do so *silently* is a more subjective assertion :-).

I did not say that *all* updating use cases are silent-updating cases.
I said that there *are* cases where one wants to update silently.  And
there are.

This is not subjective to those who use this feature (for some
bookmarks, some of the time).  Consider the use of temporary bookmarks
to bounce around positions in a buffer.  ("Temporary" can be a simple
as not saving.)

Put it another way: have you ever moved a bookmark from page 39 to
page 72 when reading a book?  That's a use case for silent updating:
manually updating the location of an existing bookmark.  You do it
when you want to do it, knowing full well that the bookmark exists.

> >That's the point of `bookmark-set': it both creates and updates.
> 
> The point of `bookmark-set' is whatever its doc string says.

Being able to either create a new bookmark or update an existing
bookmark *has been* the point of `bookmark-set' - do you prefer that
wording?

> sounds to me a bit like "bookmark-set shouldn't do
> this because this isn't the sort of thing it should do".

It conflicts with *one* of the things that it should do.  And that
it has always done.  Users should not lose the convenience of being
able to silently update.  That is one of the features that
`bookmark-set' provides.

Nothing wrong with providing additional, alternative behavior, for
other use cases.  I made that clear from the outset.  But please
do not take away the behavior that makes this use case convenient.
That's the point.

> >> 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.
> >
> >That effectively just *replaces* interactive use of `bookmark-set'
> >with the proposed alternative behavior.  That is exactly what I
> >object to.
> 
> Yes, I understand.  The discussion here is about the user-visible
> default behavior, not about how we implement it.

If you provide both behaviors then it is hard to object.  That was
*not* the proposal, however.

I would also prefer not to change the *default* behavior, but for
that I would not object strongly.  Users are used to the current
behavior of `C-x r m' - it has done what it does for a long time.
My own preference would be to give the new behavior a new binding.

But as long as both are available, the binding of each is not so
important.

> >I do not object to adding a different command, and either not
> >binding it by default (users can choose to do that) or binding
> >it to a different key.  That lets users choose the behavior they
> >want, and if they for some reason want there to be only one of
> >the behaviors then they can easily bind both keys to the same
> >command or unbind a key.
> >
> >And I do not object to adding a user option that thus conditionally
> >changes the behavior of `bookmark-set'.
> >
> >The first approach of these two alternatives gives the most
> >flexibility.  With it, they need not choose the behavior once and
> >for all but can instead just choose which behavior they want to
> >invoke in any given context.
> >
> >My point is that it is a mistake to think there is only one
> >interactive use of `bookmark-set' and that for that one use users
> >would want to be queried wrt overwriting.
> 
> No one has proposed that there is only one valid interactive use
> case; I'm not sure where you got the idea that anyone thought that.

The proposal was to *change* the interactive behavior when the
bookmark already exists (and no prefix arg).  The proposal was to
*always* query the user for confirmation in this case.  That is what
I objected to.

My point was to give users a choice in that case.  Provide two
different commands. 

> >There are lots of kinds of bookmarks, and lots of different uses of
> >bookmarks.  And some of those call precisely for silently updating
> >an existing bookmark.
> 
> Yes, and some call for warning the user.  Both scenarios happen.

Precisely.  So provide for *both* uses.  No one objected to simply
*adding* the possibility of asking for confimation.  I objected to
such a new behavior *replacing* the existing behavior of updating
silently.

My point is that silent updating is not just a mistake or a bug or
always undesirable.  And I will say the same thing about querying
for confirmation.  "Both scenarios happen", as you say.  So let's
provide users an easy way to do either, au choix.  That's the point.

Doing that will be an improvement for users rather than a loss.

> The question is not whether bookmark should offer flexibility
> (of course it should), but what its *default* interactive behavior
> should be.

No, that was exactly my question/objection: the proposal removes
flexibility and choice.  Even the existence of a silent-update use
case was questioned.

Wrt the default behavior, see above.  I do not feel strongly about
that.

> Right now, I lean toward Leo's argument that bookmark has had a
> less-than-ideal default up until now, and that his proposal is a
> better default.

Leo did *not* propose a change in default behavior.  He proposed
to replace the existing behavior and instead *always* query the
user for confirmation in the case at hand.

And that replacement is what I objected to.

You seem to be turning things around, as if the proposal gave users
a choice and I were arguing against that or I were arguing only
about a different default behavior.  Look at the proposed patch,
please.

> Silently overwriting an old bookmark loses information,
> while confirming the overwrite does not lose information.  The only
> cost is one extra interactive prompt, and *only* in the case where
> one is overwriting an existing bookmark of that name.

That is not a cost that one wants to pay needlessly, in cases where
one *expects* to move the bookmark.

Imagine if someone said to you, about your moving your bookmark in
your novel: "From now on, each time you try to move your bookmark
you will need to confirm that you really want to do that, since
this is, after all, an existing bookmark."

It seems that you have not recognized the silent-update use case,
and so have not understood why the proposed change would be
annoying, hence why users need a choice here.  I hope you understand
it now.

> I believe this is what most users would expect.

Could be.  That speaks positively for the non-silent update case.
It is not an argument for denying the silent-update case.

> (Compare: when you save a file under a new name, if there's an
> existing file of that name, you are also warned.)

We can play games with such analogies, if you like.  Updating a
bookmark is more like typing text into a buffer - *saving* your
bookmarks is something different from updating them.

Yes, some buffers are read-only, and for those an error is raised
when you type.  (But you are not warned by the action of turning
off read-only - you are not asked to confirm that change.)

> So I propose that that should be the default behavior (because
> losing information silently is usually bad), and that there can
> be a variable for you to set to get the silent-overwrite behavior
> that you prefer as the default.

No.  A variable is not user friendly.  There should be two different
commands, bound to two different keys.  It is about different use
cases - for different contexts.  It is not about different users,
some of whom always want silent updating and some of whom always
want confirmation querying.

> Equal flexibility there.  This discussion is about _defaults_.

Providing a variable as the only means to silently update does
not provide equal flexibility.

There is no need for a discussion about defaults (except for which
command goes on which key), if you provide two different commands
bound to two different keys.  And that really *does* provide
"equal flexibility".