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#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an emacsclient doesn't ask to save Date: Mon, 31 Oct 2022 21:52:12 +0200 Message-ID: <837d0fepoz.fsf@gnu.org> References: <9a70f868-ca50-52fc-af3e-23813af104f2@gmail.com> <83zgdcduxm.fsf@gnu.org> <83bkpretpn.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11005"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 58909@debbugs.gnu.org To: Jim Porter Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Oct 31 20:53:29 2022 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 1opaqe-0002m0-Vd for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 31 Oct 2022 20:53:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1opaqN-0001IX-PE; Mon, 31 Oct 2022 15:53:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1opaqF-00013E-CI for bug-gnu-emacs@gnu.org; Mon, 31 Oct 2022 15:53:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1opaqE-0000ZC-24 for bug-gnu-emacs@gnu.org; Mon, 31 Oct 2022 15:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1opaqD-0000FJ-KQ for bug-gnu-emacs@gnu.org; Mon, 31 Oct 2022 15:53:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 31 Oct 2022 19:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58909 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 58909-submit@debbugs.gnu.org id=B58909.1667245954872 (code B ref 58909); Mon, 31 Oct 2022 19:53:01 +0000 Original-Received: (at 58909) by debbugs.gnu.org; 31 Oct 2022 19:52:34 +0000 Original-Received: from localhost ([127.0.0.1]:41868 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1opapm-0000Dz-ET for submit@debbugs.gnu.org; Mon, 31 Oct 2022 15:52:34 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:35218) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1opapl-0000Dc-Hy for 58909@debbugs.gnu.org; Mon, 31 Oct 2022 15:52:34 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1opapg-0000T9-An; Mon, 31 Oct 2022 15:52:28 -0400 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=v6CAKstmXy1RZvlNm8W5QT/1JtqXjylQioojQYPteSY=; b=HQ//AqfPWtIe yuNyd2fRr29p7yc0rVmhq1AwfPFXWoK/EVjYcOeVT8KNL0zLh+Zm8/nSUXsGvofX3XoqwixKck6oz CxUaW1LB5aC69l/zOCAwp8Q6d24QWq4SoTXifG0D2MxgN67dgFpMNj0dkNKbmjUXnAOCraqJhy69p yqar46OkaSqlyF7l4Dwyw+8BugNd90obstUq/hUMz+294pnCtWbdm146iqASC6upUFMgyIv3A3M2M +sLuJ4/x2qU+JQsvVhs39R3iu8/yHBpYhXeeI/o3yi4mwr0FTx47Hel3HNQTA9kW21GYjsVyCgUkn PldqBJbOIWOHuNVQJ/dKCg==; Original-Received: from [87.69.77.57] (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 1opapf-0004sJ-9w; Mon, 31 Oct 2022 15:52:28 -0400 In-Reply-To: (message from Jim Porter on Mon, 31 Oct 2022 12:38:04 -0700) 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: , Original-Sender: "bug-gnu-emacs" Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:246717 Archived-At: > Date: Mon, 31 Oct 2022 12:38:04 -0700 > From: Jim Porter > Cc: 58909@debbugs.gnu.org > > On 10/31/2022 11:25 AM, Eli Zaretskii wrote: > >> I think it does about the same amount of harm as pressing 'C-x C-c' in > >> an emacs client. > > > > How can you say that? "C-x C-c" kills the entire terminal, whereas > > "C-x 5 0" kills just one frame! > > When there's only one frame left for the client, 'C-x 5 0' *also* kills > the entire terminal. But "C-x 5 0" doesn't have the same significance as "C-x C-c". They are different in the non-client use, and they are different in the client use. That someone could perceive them as very similar because some aspects of what they do are the same doesn't mean they are similar enough to behave the same wrt the prompt to save. > Of course, 'C-x C-c' also has the effect of killing any other frames for > that client, but that that doesn't apply there's only one frame. It would (or at least could) be possible to reason that way. But it could be argued that forcing the user to distinguish between the last "C-x 5 0" and any other is bad UI. When I type "C-x 5 0" I don't want to expect different behavior depending on how many frames the current client has. "C-x 5 0" means "delete this frame", no more, no less. > Still, > 'C-x C-c' still prompts in that case too. My understanding is that it > does so because when an application is waiting for the emacsclient to > finish, you can't go back from killing the terminal/client; you *can* > (usually) go back if you're only killing a frame. My interpretation of why "C-x C-c" prompts is that it does the same as when you use it from a non-client frame. We want the same UX in both cases. "C-x 5 0" should IMO likewise produce the same behavior in both cases. > See my other message about this too: we could make sure Emacs only > prompts the user when deleting a frame if doing so would kill a terminal > that's actually waiting for some files to be saved. If the client was > invoked with "--no-wait", we could just silently delete the frame: > there's no application waiting for a file. This has the same problem, IMO: it changes long-time behavior of client frames in incompatible ways. I don't think it's right, since the reasons for these changes are rather weak.