[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#15746: 24.3; [PATCH] bookmark should confirm when overwrite
From: |
Karl Fogel |
Subject: |
bug#15746: 24.3; [PATCH] bookmark should confirm when overwrite |
Date: |
Tue, 29 Oct 2013 15:51:48 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
Drew Adams <drew.adams@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
- bug#15746: 24.3; [PATCH] bookmark should confirm when overwrite, Leo Liu, 2013/10/28
- bug#15746: 24.3; [PATCH] bookmark should confirm when overwrite, Stefan Monnier, 2013/10/29
- bug#15746: 24.3; [PATCH] bookmark should confirm when overwrite, Drew Adams, 2013/10/29
- bug#15746: 24.3; [PATCH] bookmark should confirm when overwrite, Leo Liu, 2013/10/29
- bug#15746: 24.3; [PATCH] bookmark should confirm when overwrite, Stefan Monnier, 2013/10/29
- bug#15746: 24.3; [PATCH] bookmark should confirm when overwrite, Leo Liu, 2013/10/29
- bug#15746: 24.3; [PATCH] bookmark should confirm when overwrite, Stefan Monnier, 2013/10/29
- bug#15746: 24.3; [PATCH] bookmark should confirm when overwrite, Drew Adams, 2013/10/30