From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#15746: 24.3; [PATCH] bookmark should confirm when overwrite Date: Wed, 30 Oct 2013 07:07:59 -0700 (PDT) Message-ID: <250b9619-c6ea-49ba-ac8e-6cc40e958eee@default> References: <87iowg9bqw.fsf@floss.red-bean.com> <87ob677qcb.fsf@floss.red-bean.com> <87r4b35qh5.fsf@floss.red-bean.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1383142161 14554 80.91.229.3 (30 Oct 2013 14:09:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Oct 2013 14:09:21 +0000 (UTC) Cc: 15746@debbugs.gnu.org, Leo Liu To: Karl Fogel Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 30 15:09:25 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VbWSa-0005B0-4E for geb-bug-gnu-emacs@m.gmane.org; Wed, 30 Oct 2013 15:09:24 +0100 Original-Received: from localhost ([::1]:52580 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbWSZ-0005oh-Ft for geb-bug-gnu-emacs@m.gmane.org; Wed, 30 Oct 2013 10:09:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49811) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbWSO-0005nK-Cs for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2013 10:09:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VbWSF-0007fm-A4 for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2013 10:09:12 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbWSF-0007fa-6J for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2013 10:09:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VbWSE-0002JG-Gj for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2013 10:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Oct 2013 14:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15746 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 15746-submit@debbugs.gnu.org id=B15746.13831420918802 (code B ref 15746); Wed, 30 Oct 2013 14:09:02 +0000 Original-Received: (at 15746) by debbugs.gnu.org; 30 Oct 2013 14:08:11 +0000 Original-Received: from localhost ([127.0.0.1]:52736 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VbWRP-0002Ht-8B for submit@debbugs.gnu.org; Wed, 30 Oct 2013 10:08:11 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:25064) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VbWRM-0002Hd-Np for 15746@debbugs.gnu.org; Wed, 30 Oct 2013 10:08:09 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9UE81gv027545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Oct 2013 14:08:02 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9UE81hk009901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 14:08:01 GMT Original-Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9UE81RC020849; Wed, 30 Oct 2013 14:08:01 GMT In-Reply-To: <87r4b35qh5.fsf@floss.red-bean.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:79783 Archived-At: > >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. >=20 > That's another solution, hmmm, but it seems to me it complexifies > the user interface a bit=20 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". >=20 > 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.