From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] When deleting in bookmark menu, prompt for confirmation. Date: Wed, 05 May 2021 14:37:37 -0500 Message-ID: <878s4tq8e6.fsf@red-bean.com> References: <87a6pcqy7s.fsf@red-bean.com> <83czu86o46.fsf@gnu.org> <835z006jpl.fsf@gnu.org> <87im3z3f8f.fsf@red-bean.com> <83zgxb67g2.fsf@gnu.org> <87mtt9sqh4.fsf@red-bean.com> <87czu58uso.fsf@gnus.org> Reply-To: Karl Fogel Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19809"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 05 21:39:06 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1leNMP-0004yh-27 for ged-emacs-devel@m.gmane-mx.org; Wed, 05 May 2021 21:39:05 +0200 Original-Received: from localhost ([::1]:50650 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1leNMO-0005Qn-4I for ged-emacs-devel@m.gmane-mx.org; Wed, 05 May 2021 15:39:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47648) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1leNL6-0004Zd-I3 for emacs-devel@gnu.org; Wed, 05 May 2021 15:37:44 -0400 Original-Received: from sanpietro.red-bean.com ([45.79.25.59]:36182) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1leNL2-0007ED-Fy for emacs-devel@gnu.org; Wed, 05 May 2021 15:37:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=red-bean.com; s=202005newsp; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:Reply-To:References:Subject:Cc:To:From:Sender: Content-Transfer-Encoding:Content-ID:Content-Description; bh=InuDfIHa5fgOmZexgJ67AAoKdHntM82OfdWZ41v+JqQ=; t=1620243459; x=1621453059; b=cUxGkXi6Cm91lreX0OgvjvGTD8IIZZeKXJYckfcf5T/RwqVMQORdSkn3MZ/JQ97H/IAiGndj5p 3vuTrXS/6aIy5Zuv9DCXhP0e/CW/88Wpb8kQr4H4ReNi7+yIjG+XKwshlWzGIQcNihFckblFaQMPO s4Fkwa3HTV37lq/A4H5YqEqQDx5RNLqaQaFOfau2hCTvRKwu17khmB1HISBo6gKNSKoXXIxYCzra+ 9EFhlgpiffGsgeqwqFZY67ZRcDnJb5fbRkR73IebKhK5iRUldk00uiljacJ4bmXze+iTvL2pqhEmT UkwX/bU+Sh5/q1vAEVvWZqdzS0U2CSh4ilFxw==; Original-Received: from [12.106.183.66] (port=17550 helo=kwork) by sanpietro.red-bean.com with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1leNL0-0005E8-Os; Wed, 05 May 2021 19:37:38 +0000 In-Reply-To: <87czu58uso.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 05 May 2021 10:11:03 +0200") Received-SPF: pass client-ip=45.79.25.59; envelope-from=kfogel@red-bean.com; helo=sanpietro.red-bean.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:268923 Archived-At: On 05 May 2021, Lars Ingebrigtsen wrote: >Karl Fogel writes: > >> Revised patch attached, with the option now defaulting to nil >> (i.e., >> to the old behavior) as per discussion. Review/comments >> welcome. >> >> Lars, you wrote this regarding v1 of this patch: >> >>> ...the first line [of the doc string] should be a complete >>> sentence. >> >> It actually was a complete sentence even in v1, but I think I >> know >> what you meant. However, the "Non-nil means..." phrasing is >> found >> throughout Emacs -- I counted over 1000 places with this quick >> check: > >What I meant was that the first line should be a complete >sentence. :-) Ah, right! I forgot that sometimes "line" means literally "line", right. Ahem. Sorry :-). You said exactly what you meant, and I somehow read something different. >In any case, as I said -- I don't think adding this user option >makes a >lot of sense. Instead bookmark should implement "undo" >functionality. Hmm, I can understand, but... let me give you my best argument for why to do this instead of implementing undo: First of all, I think this option is useful on its own, with or without undo. It did come from a user request, after all, which was seconded (on Emacs Humanities) by at least one other person besides me. Giving people the ability to prevent the bad thing from happening is not the same as giving them ability to recover if the bad thing happens. Also, implementing undo functionality would open up a whole lot of questions. If Bookmark Menu mode supports undo, do Bookmark operations in general support undo? If so, which ones? And even just within Bookmark Menu, what else should be undo-able? Renaming? What about retargeting? And there's the usual bevy of undo-boundary questions: suppose someone does 'x' to execute deletions, then 's' to save the current state of the bookmarks list. If they then undo, should it undo the deletions but not save the result, or should it also save? Personally, I'm not prepared to go down this road; it's a lot of work and complexity. The situation that needed addressing in Bookmark Menu was simply that it's too easy to accidentally hit 'x' and delete things that you weren't ready to delete. Solving this one problem, in the same way that Dired solves it, seems clean and useful to me. >And adding the option, but defaulting to nil, makes even less >sense -- >nobody is going to discover this option unless it defaults to t. Well, there is the etc/NEWS entry, but still I kind of agree with you. I would have chosen the default-to-true route, though Eli's preference for the other way is perfectly reasonable; this isn't a One Right Way situation IMHO. Discoverability problems would exist with undo, too, of course. Best regards, -Karl