GNU bug report logs - #15746
24.3; [PATCH] bookmark should confirm when overwrite

Previous Next

Full log

Message #17 received at 15746 <at> debbugs.gnu.org (full text, mbox):

From: Karl Fogel <kfogel <at> red-bean.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15746 <at> debbugs.gnu.org, Leo Liu <sdl.web <at> gmail.com>
Subject: Re: bug#15746: 24.3; [PATCH] bookmark should confirm when overwrite
Date: Tue, 29 Oct 2013 15:51:48 -0500

Drew Adams <drew.adams <at> oracle.com> writes:
>> 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.
>
>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 :-).

>That's the point of `bookmark-set': it both creates and updates.

The point of `bookmark-set' is whatever its doc string says.  As long as
we don't break compatibility in some silly way, we can change its
behavior.

I realize I'm driving the point home a bit hard here, but this part of
your argument sounds to me a bit like "bookmark-set shouldn't do this
because this isn't the sort of thing it should do".

>> 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.

>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.

>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.  The
question is not whether bookmark should offer flexibility (of course it
should), but what its *default* interactive behavior should be.

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.  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.  I believe this is what
most users would expect.  (Compare: when you save a file under a new
name, if there's an existing file of that name, you are also warned.)

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.

Equal flexibility there.  This discussion is about _defaults_.

Best,
-K

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.