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: Tue, 29 Oct 2013 15:16:02 -0700 (PDT) Message-ID: References: <87iowg9bqw.fsf@floss.red-bean.com> <87ob677qcb.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 1383085041 10991 80.91.229.3 (29 Oct 2013 22:17:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Oct 2013 22:17: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 Tue Oct 29 23:17:24 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 1VbHbG-0005Oo-JH for geb-bug-gnu-emacs@m.gmane.org; Tue, 29 Oct 2013 23:17:22 +0100 Original-Received: from localhost ([::1]:49624 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbHbF-0003Ww-TP for geb-bug-gnu-emacs@m.gmane.org; Tue, 29 Oct 2013 18:17:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46471) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbHb4-0003Wb-S1 for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2013 18:17:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VbHaw-0008Ht-7P for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2013 18:17:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37584) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbHaw-0008Ho-3o for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2013 18:17:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VbHav-00059z-PN for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2013 18:17:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Oct 2013 22:17:01 +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.138308497519770 (code B ref 15746); Tue, 29 Oct 2013 22:17:01 +0000 Original-Received: (at 15746) by debbugs.gnu.org; 29 Oct 2013 22:16:15 +0000 Original-Received: from localhost ([127.0.0.1]:51603 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VbHaA-00058n-CX for submit@debbugs.gnu.org; Tue, 29 Oct 2013 18:16:15 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:29492) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VbHa7-00058U-Kf for 15746@debbugs.gnu.org; Tue, 29 Oct 2013 18:16:12 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9TMG4wQ028010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Oct 2013 22:16:05 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9TMG3YN003600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 22:16:04 GMT Original-Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9TMG3a7027626; Tue, 29 Oct 2013 22:16:03 GMT In-Reply-To: <87ob677qcb.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: acsinet22.oracle.com [141.146.126.238] 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:79760 Archived-At: > >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 :-). I did not say that *all* updating use cases are silent-updating cases. I said that there *are* cases where one wants to update silently. And there are. This is not subjective to those who use this feature (for some bookmarks, some of the time). Consider the use of temporary bookmarks to bounce around positions in a buffer. ("Temporary" can be a simple as not saving.) Put it another way: have you ever moved a bookmark from page 39 to page 72 when reading a book? That's a use case for silent updating: manually updating the location of an existing bookmark. You do it when you want to do it, knowing full well that the bookmark exists. > >That's the point of `bookmark-set': it both creates and updates. >=20 > The point of `bookmark-set' is whatever its doc string says. Being able to either create a new bookmark or update an existing bookmark *has been* the point of `bookmark-set' - do you prefer that wording? > sounds to me a bit like "bookmark-set shouldn't do > this because this isn't the sort of thing it should do". It conflicts with *one* of the things that it should do. And that it has always done. Users should not lose the convenience of being able to silently update. That is one of the features that `bookmark-set' provides. Nothing wrong with providing additional, alternative behavior, for other use cases. I made that clear from the outset. But please do not take away the behavior that makes this use case convenient. That's the point. > >> 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. >=20 > Yes, I understand. The discussion here is about the user-visible > default behavior, not about how we implement it. If you provide both behaviors then it is hard to object. That was *not* the proposal, however. I would also prefer not to change the *default* behavior, but for that I would not object strongly. Users are used to the current behavior of `C-x r m' - it has done what it does for a long time. My own preference would be to give the new behavior a new binding. But as long as both are available, the binding of each is not so important. > >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. >=20 > 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. The proposal was to *change* the interactive behavior when the bookmark already exists (and no prefix arg). The proposal was to *always* query the user for confirmation in this case. That is what I objected to. My point was to give users a choice in that case. Provide two different commands.=20 > >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. >=20 > Yes, and some call for warning the user. Both scenarios happen. Precisely. So provide for *both* uses. No one objected to simply *adding* the possibility of asking for confimation. I objected to such a new behavior *replacing* the existing behavior of updating silently. My point is that silent updating is not just a mistake or a bug or always undesirable. And I will say the same thing about querying for confirmation. "Both scenarios happen", as you say. So let's provide users an easy way to do either, au choix. That's the point. Doing that will be an improvement for users rather than a loss. > The question is not whether bookmark should offer flexibility > (of course it should), but what its *default* interactive behavior > should be. No, that was exactly my question/objection: the proposal removes flexibility and choice. Even the existence of a silent-update use case was questioned. Wrt the default behavior, see above. I do not feel strongly about that. > 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. Leo did *not* propose a change in default behavior. He proposed to replace the existing behavior and instead *always* query the user for confirmation in the case at hand. And that replacement is what I objected to. You seem to be turning things around, as if the proposal gave users a choice and I were arguing against that or I were arguing only about a different default behavior. Look at the proposed patch, please. > 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. That is not a cost that one wants to pay needlessly, in cases where one *expects* to move the bookmark. Imagine if someone said to you, about your moving your bookmark in your novel: "From now on, each time you try to move your bookmark you will need to confirm that you really want to do that, since this is, after all, an existing bookmark." It seems that you have not recognized the silent-update use case, and so have not understood why the proposed change would be annoying, hence why users need a choice here. I hope you understand it now. > I believe this is what most users would expect. Could be. That speaks positively for the non-silent update case. It is not an argument for denying the silent-update case. > (Compare: when you save a file under a new name, if there's an > existing file of that name, you are also warned.) We can play games with such analogies, if you like. Updating a bookmark is more like typing text into a buffer - *saving* your bookmarks is something different from updating them. Yes, some buffers are read-only, and for those an error is raised when you type. (But you are not warned by the action of turning off read-only - you are not asked to confirm that change.) > 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. 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. > Equal flexibility there. This discussion is about _defaults_. 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".