From: Drew Adams <drew.adams@oracle.com>
To: Karl Fogel <kfogel@red-bean.com>
Cc: 15746@debbugs.gnu.org, Leo Liu <sdl.web@gmail.com>
Subject: bug#15746: 24.3; [PATCH] bookmark should confirm when overwrite
Date: Wed, 30 Oct 2013 07:07:59 -0700 (PDT) [thread overview]
Message-ID: <250b9619-c6ea-49ba-ac8e-6cc40e958eee@default> (raw)
In-Reply-To: <87r4b35qh5.fsf@floss.red-bean.com>
> >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.
>
> That's another solution, hmmm, but it seems to me it complexifies
> the user interface a bit
It's a lot simpler for a user than changing a variable value for one
bookmark update (w/o confirmation) and changing it again for another
update (w/ confirmation).
> (it adds another binding in the keyspace, which the user then cannot
> avoid encountering when looking at the available bound commands
That's a good thing. Helps users see that both possibilities exist.
> -- whereas a variable is something they only need to deal with
> if/when they go looking for it, read the documentation, etc).
Which is not a thing. And `C-h m' and `C-h b' *are* part of the
documentation.
> So I'm not sure which way is better; I think we might be down to
> the "tyranny of small differences" at that point :-).
If you take the point of view that both are useful behaviors for a
user to have (even the same user, in different contexts), and that
it should be easy to use either of them, then having two commands
recommends itself as the way to go. If you don't want to provide
key bindings for both commands, fine (but too bad).
> >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".
>
> As far as that assertion goes, it is true, yes. It doesn't address
> the keyspace complexity issue.
I don't see a keyspace complexity issue here. Having both `C-x r m'
and, say, `C-x r M', which do almost the same thing, sounds quite
reasonable, to me.
next prev parent reply other threads:[~2013-10-30 14:07 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
2013-10-29 22:16 ` Drew Adams
2013-10-30 4:31 ` Karl Fogel
2013-10-30 14:07 ` Drew Adams [this message]
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=250b9619-c6ea-49ba-ac8e-6cc40e958eee@default \
--to=drew.adams@oracle.com \
--cc=15746@debbugs.gnu.org \
--cc=kfogel@red-bean.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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).