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 16:38:10 -0500 Message-ID: <874kfguail.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> <878s4tq8e6.fsf@red-bean.com> 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="5388"; 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: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 05 23:55: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 1lePUA-0001IJ-RE for ged-emacs-devel@m.gmane-mx.org; Wed, 05 May 2021 23:55:14 +0200 Original-Received: from localhost ([::1]:49176 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lePU9-0008Mt-Qb for ged-emacs-devel@m.gmane-mx.org; Wed, 05 May 2021 17:55:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45914) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lePDi-000120-9Q for emacs-devel@gnu.org; Wed, 05 May 2021 17:38:14 -0400 Original-Received: from sanpietro.red-bean.com ([45.79.25.59]:37222) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lePDg-0002wg-5p for emacs-devel@gnu.org; Wed, 05 May 2021 17:38:14 -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=3w7SJ/3+txVRsegfASnPxYR1wxUJhcjIWc0NT4mhPS4=; t=1620250691; x=1621460291; b=HoiLjP2FDf/CFxlxqRGA4Nal3hPsdG+Zi5BPg4or3vXopo84YoySM9usD/SXRWEtfjphxYvmKf 3d5d4/1nLQn+b3PLzFs7tANnB1GZInwY95MQz6EXfOU7uyIinAo7VR65B+9mdoEFJRLorHvWNuR/t xDZnKpNuchMLP1ky7BT+J1eREho6nBMF8f7ZxSUwBDNmlQYh1HY1JOzXCucJgUbutbSEP6N8hnasH zP4bmGeXyFO3VLoQ/8Ps1yW41IhX3kZ9ILzECRRk2qHuUIjKMOb7ce6+XL/O3AEr3XH9UABD46WpW acrbaSaKcqa+M5/1gJx3Fd5dG4pmF/CKT4+JA==; Original-Received: from [12.106.183.66] (port=49341 helo=kwork) by sanpietro.red-bean.com with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lePDe-0007ak-KL; Wed, 05 May 2021 21:38:10 +0000 In-Reply-To: (Stefan Monnier's message of "Wed, 05 May 2021 16:06:10 -0400") 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:268940 Archived-At: On 05 May 2021, Stefan Monnier wrote: >> 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. Glad to hear that. +1 to the rest of your analysis below, too, including that last part about how for undo purposes the Bookmark Menu buffer can be thought of as "visiting" the file in which bookmarks are saved. (However, users are much less directly exposed to the bookmark file than they are to the regular kind of file that one visits, edits, and saves -- so the analogy fits mostly but perhaps not perfectly. A person could in theory use bookmarks regularly without ever needing to be aware that the file even exists.) I don't plan to implement the undo functionality myself. It's a larger task than I want to take on. Or rather, if I were going to find time to do something of that size in Emacs, there are other things I would pick before this. However, it's good to have all these thoughts archived here, in case anyone else decides to do it. Best regards, -Karl >> 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