From: Karl Fogel <kfogel@red-bean.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: 15746@debbugs.gnu.org, Leo Liu <sdl.web@gmail.com>
Subject: bug#15746: 24.3; [PATCH] bookmark should confirm when overwrite
Date: Tue, 29 Oct 2013 15:51:48 -0500 [thread overview]
Message-ID: <87ob677qcb.fsf@floss.red-bean.com> (raw)
In-Reply-To: <f5f3d839-2c03-4572-806c-daf95a7bf921@default> (Drew Adams's message of "Tue, 29 Oct 2013 13:09:24 -0700 (PDT)")
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
next prev parent reply other threads:[~2013-10-29 20:51 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-29 3:32 bug#15746: 24.3; [PATCH] bookmark should confirm when overwrite Leo Liu
2013-10-29 14:20 ` Drew Adams
2013-10-29 18:24 ` Karl Fogel
2013-10-29 20:09 ` Drew Adams
2013-10-29 20:51 ` Karl Fogel [this message]
2013-10-29 22:16 ` Drew Adams
2013-10-30 4:31 ` Karl Fogel
2013-10-30 14:07 ` Drew Adams
2013-10-30 2:11 ` Stefan Monnier
2013-10-30 2:35 ` Drew Adams
2013-10-30 2:56 ` Leo Liu
2013-10-30 3:14 ` Stefan Monnier
2013-10-30 3:36 ` Leo Liu
2013-10-30 3:57 ` Stefan Monnier
2013-10-30 14:07 ` Drew Adams
2013-10-30 18:17 ` Stefan Monnier
2013-10-30 1:28 ` Leo Liu
2013-10-30 2:26 ` Drew Adams
2015-11-08 19:27 ` bug#15746: Fix committed to master Karl Fogel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ob677qcb.fsf@floss.red-bean.com \
--to=kfogel@red-bean.com \
--cc=15746@debbugs.gnu.org \
--cc=drew.adams@oracle.com \
--cc=sdl.web@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.