From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.bugs Subject: bug#15746: 24.3; [PATCH] bookmark should confirm when overwrite Date: Tue, 29 Oct 2013 15:51:48 -0500 Message-ID: <87ob677qcb.fsf@floss.red-bean.com> References: <87iowg9bqw.fsf@floss.red-bean.com> Reply-To: Karl Fogel NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1383079936 16679 80.91.229.3 (29 Oct 2013 20:52:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Oct 2013 20:52:16 +0000 (UTC) Cc: 15746@debbugs.gnu.org, Leo Liu To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 29 21:52:19 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 1VbGGv-0002zS-5N for geb-bug-gnu-emacs@m.gmane.org; Tue, 29 Oct 2013 21:52:17 +0100 Original-Received: from localhost ([::1]:49348 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbGGu-0002sz-QC for geb-bug-gnu-emacs@m.gmane.org; Tue, 29 Oct 2013 16:52:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbGGm-0002sn-Pw for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2013 16:52:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VbGGh-00072D-DM for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2013 16:52:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37526) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbGGh-000725-9j for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2013 16:52:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VbGGg-00033R-LR for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2013 16:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Karl Fogel Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Oct 2013 20:52: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.138307991911732 (code B ref 15746); Tue, 29 Oct 2013 20:52:02 +0000 Original-Received: (at 15746) by debbugs.gnu.org; 29 Oct 2013 20:51:59 +0000 Original-Received: from localhost ([127.0.0.1]:51545 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VbGGc-000339-Gu for submit@debbugs.gnu.org; Tue, 29 Oct 2013 16:51:59 -0400 Original-Received: from mail-ie0-f177.google.com ([209.85.223.177]:33931) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VbGGZ-00032v-SZ for 15746@debbugs.gnu.org; Tue, 29 Oct 2013 16:51:56 -0400 Original-Received: by mail-ie0-f177.google.com with SMTP id e14so730667iej.36 for <15746@debbugs.gnu.org>; Tue, 29 Oct 2013 13:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:reply-to:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=/hqohzIfsXNDDbrY84ZEjWbrYcH6+eCA8hjZmCnWueg=; b=S8sCJ3EJVyUvM1duyGNfY1PiwywbzfIKImhUGATXgQ3eCRmJT/98d3doW6Cg9waMYM pWci9E/c3hdpi8fDlnKO/4YIfPdLLzNuZvbF2tDyi9ly4NLfeqI+sjankJnBRhzZFytG nYmE14xWJaC5K8z+S1O8RtuPK3d9XI2uQCU9DwwoIJmUqsGx+Yy9gqPV8t/C0VoXk1V2 RvwtvOipGbGIp8KVj/pFLX7cuj7gcLmkP5puGDodCY72ICbo95HNyW0xtI/+PXKQpfsZ l2xxUojmP7hmrhp2U6sos1gIjtdm7CTkBaXSblLAvUM9BOFkBvuGlfzNi3J4nd/00i5O 8Y7w== X-Received: by 10.50.72.33 with SMTP id a1mr14011876igv.58.1383079909968; Tue, 29 Oct 2013 13:51:49 -0700 (PDT) Original-Received: from floss.red-bean.com (64-145-114-106.client.dsl.net. [64.145.114.106]) by mx.google.com with ESMTPSA id y10sm3824832igl.4.2013.10.29.13.51.49 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 29 Oct 2013 13:51:49 -0700 (PDT) In-Reply-To: (Drew Adams's message of "Tue, 29 Oct 2013 13:09:24 -0700 (PDT)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) 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:79759 Archived-At: Drew Adams 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