From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] When deleting in bookmark menu, prompt for confirmation. Date: Wed, 05 May 2021 16:06:10 -0400 Message-ID: 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> <878s4tq8e6.fsf@red-bean.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35999"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Lars Ingebrigtsen , emacs-devel@gnu.org To: Karl Fogel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 05 22:08:14 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 1leNoc-0009BS-2b for ged-emacs-devel@m.gmane-mx.org; Wed, 05 May 2021 22:08:14 +0200 Original-Received: from localhost ([::1]:51654 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1leNob-0001lU-3J for ged-emacs-devel@m.gmane-mx.org; Wed, 05 May 2021 16:08:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53554) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1leNmk-0000Y6-4E for emacs-devel@gnu.org; Wed, 05 May 2021 16:06:18 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:18658) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1leNmg-0006g5-UC for emacs-devel@gnu.org; Wed, 05 May 2021 16:06:17 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5BDFD1001FB; Wed, 5 May 2021 16:06:13 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id AD07010019F; Wed, 5 May 2021 16:06:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1620245171; bh=sbA38KTcV9SBoxqsb2sTw7on9EknLE31DDY70F3h2Ig=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Swc7+TK1VjHGLCYZwknkSR3iof34S9cH8N6x+2pEY7RC1gRcRPk7BN6ArU1wsWFLF RVOG3whDhBH+Z5IUeIs+W7hb+2OKsXWYbGHGFKs5aXGbvKT/1tDK5tL6amnduFg+6/ OyQYkZoPHi6aMcH/br/6G3fhds0BzEFPBa7sJqs21IkWskEh1OrYRPZUCVs5rdBGQZ u9quLFF9DsJ84JSR5Cr6k6MBGnZ1X46MQ/mPz0hqVGC/t9I5Pp76rgYxCMNyAhxyUU z2RI230chRyl/9Rk0/SB85KfUw0+jbUmmXGbm2hXin2mq5D5KPNp2JZ4AqRvFmMY4p lR7pE8a1YtexA== Original-Received: from alfajor (76-10-140-76.dsl.teksavvy.com [76.10.140.76]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7433B12061F; Wed, 5 May 2021 16:06:11 -0400 (EDT) In-Reply-To: <878s4tq8e6.fsf@red-bean.com> (Karl Fogel's message of "Wed, 05 May 2021 14:37:37 -0500") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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:268931 Archived-At: > Hmm, I can understand, but... let me give you my best argument for why to do > this instead of implementing undo: Makes a lot of sense to me, yes. While the idea of "undo" was brought up in response to your proposal and can indeed be seen as providing a similar functionality, I think the two are mostly orthogonal. > First of all, I think this option is useful on its own, with or without > undo. Agreed. And similarly undo would be useful with or without such a confirmation prompt. > Also, implementing undo functionality would open up a whole lot > of questions. Yes, it's an interesting field. I hope someone will tackle this problem. > If Bookmark Menu mode supports undo, do Bookmark operations in > general support undo? I'd say yes, but in order to save the user the trouble of saying "undo bookmark operation" (as opposed to undoing other things), I think it's OK to limit oneself to supporting the `undo` command within the bookmark-menu buffer. I think to make it work well, we'd also want to make sure the bookmark menu is always up-to-date with the bookmark data structure (i.e. any external change to the bookmarks would be immediately reflected in a bookmark menu if there is one (with a corresponding undo entry)). > If so, which ones? And even just within Bookmark > Menu, what else should be undo-able? I think it would make sense to make "everything" in there undoable. We might even be able to support `undo-in-region` ;-) > 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? If you think of the bookmark-menu as the buffer that visits the bookmark file, then it would be natural that "save" is not part of the operations that are recorded in the undo log (and the `**` in the modeline might try and reflect the "saved" state like we do for normal files). Stefan