From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#51883: 29.0.50; Command to get accidentally deleted frames back Date: Wed, 17 Nov 2021 15:11:36 +0200 Message-ID: <83tugbyliv.fsf@gnu.org> References: <87czn1gfb1.fsf@web.de> <838rxo0zk7.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4684"; mail-complaints-to="usenet@ciao.gmane.io" Cc: michael_heerdegen@web.de, 51883@debbugs.gnu.org, juri@linkov.net To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 17 14:12:21 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1mnKjc-00014f-5W for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 17 Nov 2021 14:12:20 +0100 Original-Received: from localhost ([::1]:60328 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mnKja-0007RX-Fn for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 17 Nov 2021 08:12:18 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:59596) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mnKjK-0007Px-Ol for bug-gnu-emacs@gnu.org; Wed, 17 Nov 2021 08:12:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48878) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mnKjK-0001QD-GI for bug-gnu-emacs@gnu.org; Wed, 17 Nov 2021 08:12:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mnKjK-00009T-8k for bug-gnu-emacs@gnu.org; Wed, 17 Nov 2021 08:12:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 17 Nov 2021 13:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51883 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 51883-submit@debbugs.gnu.org id=B51883.1637154713565 (code B ref 51883); Wed, 17 Nov 2021 13:12:02 +0000 Original-Received: (at 51883) by debbugs.gnu.org; 17 Nov 2021 13:11:53 +0000 Original-Received: from localhost ([127.0.0.1]:60424 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mnKjB-000092-B5 for submit@debbugs.gnu.org; Wed, 17 Nov 2021 08:11:53 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:58786) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mnKj6-00008c-KD for 51883@debbugs.gnu.org; Wed, 17 Nov 2021 08:11:52 -0500 Original-Received: from [2001:470:142:3::e] (port=58546 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mnKj0-0001Ns-M6; Wed, 17 Nov 2021 08:11:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=DvxBcrUZf+VVqybZD0H1czztaPmMJLrkS6XL/8jd588=; b=bKXxdQkry1rD CcZfw/vNnCxdcB4TbI+Nzp1eCoOxyvmoy1FAkdWwM5raKbJqWui3U+5uB3KnIfV8zmW9MtM3JSxJ+ M23S2crRhj4vGVnSmhXRI4O5zqQeDBLnF8jJjty+0mBM57SMineQk6+roeZC1RhqBuqW4Jrc1umlP 0eoPLbNsEJbMiKdQbgRxt6VcoxF01VhgKLBNiH+CATTm02pZI285qFlA/+0RyiRuSWP0O6LBsPlN7 Wjw+zbfHq0bIUaTZM+f8NC15hn+kvd9fopf+kfh+uXJxyk+GkinU7TE/zWKlHeh4QwQG3tS+sgYTM tq6DahRQFqOl47hOIazTDw==; Original-Received: from [87.69.77.57] (port=4932 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mnKj0-0001jo-4t; Wed, 17 Nov 2021 08:11:42 -0500 In-Reply-To: (message from Gregory Heytings on Tue, 16 Nov 2021 21:29:35 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:220198 Archived-At: > Date: Tue, 16 Nov 2021 21:29:35 +0000 > From: Gregory Heytings > cc: 51883@debbugs.gnu.org, Juri Linkov , > michael_heerdegen@web.de > > Updated patch attached, which incorporates your comments and Juri's > suggestion. > > > This is unusual meaning of prefix argument. Why not use zero for the > > last, 1 for the one before that, etc.? > > You mean: 0 for the least recently deleted one, and 15 for the most > recently deleted one? So to recover the frame you just deleted by > accident, you'd have to type C-u 15 C-x 5 u? That seems unnatural to me, > but perhaps it's just me. No, I mean "last" as in "the most recently deleted one". Sorry for being unclear. Usually, commands that use both numeric and raw prefix arg do something very different with the raw argument, which is not the case here. > A minor mode is another option, indeed. My feeling is that this feature > is something about everyone would find useful, and that the cost you > mention is not that high. And I solved the problem of the deletion of the > terminal frame. So I made it an opt-out minor-mode. I'd prefer to make it opt-in. I see no reason to force on everyone a new feature that doesn't sound like it's urgent or important enough to justify the behavior change. Even though the memory it uses is not large, it's still memory, and it still increases consing each time a frame is deleted. For example, some people turn on all kinds of optional features that pop up new frames in many situations, and who knows what this will cause in those usage patterns. Why risk such unintended consequences on behalf of a minor feature? As a nice bonus, making it opt-in will also allow to make the implementation cleaner: no need for special handling of the initial frame etc. > > The "however" part is "out of the blue" here; I'd drop it. > > > > I see what you mean, but it's not out of the blue, it's meant to balance > the "permanently eliminating" in "Delete FRAME, permanently eliminating it > from use." two lines above. > + (and (not (display-graphic-p)) > + (seq-every-p > + (lambda (f) (not (frame-parameter f 'display))) > + (frame-list)))) This should have a comment explaining what it does and why. (And I hope we will be able to avoid doing that in the first place.) Also, what happens with the daemon frame if this function is invoked from a GUI frame? > +Without a prefix argument, or with a non-numerical prefix argument, This is better rephrased as ... or with just \\[universal-argument], ... since "non-numerical prefix argument" will not necessarily be clear to everyone quickly enough. > + (bindings--define-key menu [undelete-last-deleted-frame] > + '(menu-item "Undelete Frame" undelete-frame > + :enable undelete-frame-mode > + :help "Undelete last deleted frame")) How about using "restore" instead of "undelete", here and everywhere else? I think it's a tad more clear, and also easier to understand, as it doesn't use negative tense. > doc: /* Delete FRAME, permanently eliminating it from use. > FRAME must be a live frame and defaults to the selected one. > > +The 16 most recently deleted frames can however be undeleted with > +`undelete-frame', which see. If "however" is because of "permanently", I'd rather we lost both. It makes little sense to say something and then contradict ourselves 2 sentences later. The doc string should also mention the minor mode, because without it the added sentence is inaccurate. Thanks.