From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jim Porter Newsgroups: gmane.emacs.bugs Subject: bug#51993: 29.0.50; [PATCH] Killing emacsclient terminal with `server-stop-automatically' doesn't prompt to save files Date: Tue, 23 Nov 2021 17:10:38 -0800 Message-ID: References: <9e47c871-a2c3-d764-bec9-d87abf3efe83@gmail.com> <83pmqvti49.fsf@gnu.org> <890d44ded2b56811ceff@heytings.org> <64c7eb70-d941-9c98-4513-a2bdc44e7953@gmail.com> <890d44ded2fa8ff77ab2@heytings.org> <1623621b-d2a6-a68c-ac28-cdd371886b11@gmail.com> <890d44ded2c42fe531a1@heytings.org> <60d6439a-d2be-cbb4-b979-312a35216758@gmail.com> <890d44ded244c5e34000@heytings.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9086"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 51993@debbugs.gnu.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 24 02:11:38 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 1mpgp0-00028i-2l for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 24 Nov 2021 02:11:38 +0100 Original-Received: from localhost ([::1]:42632 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mpgoy-0002kx-De for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 23 Nov 2021 20:11:36 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:57852) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mpgoS-0002fy-A9 for bug-gnu-emacs@gnu.org; Tue, 23 Nov 2021 20:11:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40993) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mpgoQ-0006L6-Fl for bug-gnu-emacs@gnu.org; Tue, 23 Nov 2021 20:11:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mpgoQ-0004GY-2B for bug-gnu-emacs@gnu.org; Tue, 23 Nov 2021 20:11:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jim Porter Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Nov 2021 01:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 51993-submit@debbugs.gnu.org id=B51993.163771624816370 (code B ref 51993); Wed, 24 Nov 2021 01:11:02 +0000 Original-Received: (at 51993) by debbugs.gnu.org; 24 Nov 2021 01:10:48 +0000 Original-Received: from localhost ([127.0.0.1]:52539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mpgoB-0004Fy-Lh for submit@debbugs.gnu.org; Tue, 23 Nov 2021 20:10:48 -0500 Original-Received: from mail-pg1-f176.google.com ([209.85.215.176]:38824) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mpgo9-0004Fg-Kq for 51993@debbugs.gnu.org; Tue, 23 Nov 2021 20:10:46 -0500 Original-Received: by mail-pg1-f176.google.com with SMTP id s137so605674pgs.5 for <51993@debbugs.gnu.org>; Tue, 23 Nov 2021 17:10:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=4sAkP+lYFd8DZvUREODwrzqcwJLKX9sFdE+xkO6XHc0=; b=ICyWSEaZgRcNkt2Mhxq098y9F92dTj8a5Q6ZmfQbmH5krEUSs1tSU1XQqoSxbafoPJ vclCvt8X6qolQEpLjEQkB3TFYWAeFCAgjgQjqpxY+B5jD229hRHJT6dOGfAsXkndeq+S XWNovrphiSpDZYz4iiXupbSLQiBFmrkx8e2xUWL/0yvmRNkii8hIK3BxIfAECLl7/Ut0 lPyLlgSkIVwmn2j0FnD1YPjcRVQCjrHNfUIwmbxV02nSqiiOjsCIYlZdtkNbhz/kT3Ol jDc6y0330/D+SpHkL5MBdx7n9+dfBYPwt/yS5LRkeucZJ8hGjCVMBSIHG6q1sBkrYlyX bCgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4sAkP+lYFd8DZvUREODwrzqcwJLKX9sFdE+xkO6XHc0=; b=mcS3ABzDBHn33f2dNDooQg40rGicLocyn06XYrS4glqrdqlCywMTvxkvO7B96QQx0E YVfCTe7yp0cbF/ykjWlz17pncB2x1xOh2/OeGqVBxmsbmPKLtvkiWbMb4eREKcK5UiBj XYvg6vy2wAEu5Eq2phRAVylmwZn4H5I2hVQoJEOncnPaaeOboEr1PAQTm7+4PORY3B6s yW1w9qXKqWoSItP8ShRfZr4NHLQHJnXsrqYDlQ7H8TTTUPoVOtDlryMC/cK9PsAHV0rS Y1NotSbHTVszYUmSp54Pke4g/4UnkGiY5GRCAuFZulcUGCdJ4TVAsiqmRMOKPMiz345u M+MQ== X-Gm-Message-State: AOAM532qM0Cv3iOmV1UH76rDk//TaWtc+Lq8N9CpmeUphcdTHLklNa3y 0t6sHHB22YZYegjm46EhLLHaXWNr3CI= X-Google-Smtp-Source: ABdhPJzdcrY7UkdBaxJXr6ZdE5Mud0qT75EYTZETU31+Dgz7UVQZMGJCf/R7Vl0aSnU+E0W4VKPgWQ== X-Received: by 2002:a65:6554:: with SMTP id a20mr6982634pgw.107.1637716239693; Tue, 23 Nov 2021 17:10:39 -0800 (PST) Original-Received: from [192.168.1.2] (cpe-76-168-148-233.socal.res.rr.com. [76.168.148.233]) by smtp.googlemail.com with ESMTPSA id t10sm1087888pga.6.2021.11.23.17.10.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Nov 2021 17:10:39 -0800 (PST) In-Reply-To: <890d44ded244c5e34000@heytings.org> Content-Language: en-US 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:220697 Archived-At: On 11/23/2021 3:59 PM, Gregory Heytings wrote: >> >> I never posted a rigorous specification of the behavior I wanted for >> that reason: I was soliciting feedback to develop a patch that meets >> my needs. >> > > That's not what you did, you posted a patch claiming that one of the > existing behaviors had a bug and should be replaced with another one. That's in reference to my original message on Oct 19[1], which I cited earlier in the paragraph that you excerpted the quote from. At the time, I said: > I didn't see any options to configure this behavior in Emacs, but > looking over the code, it shouldn't be that hard for me to write a patch > to add this as an option. Before I started though, I wanted to see what > others thought. Is this a behavior others would be interested in? If so, > are there any other particulars I should take into account in my patch? -------------------- On 11/23/2021 3:59 PM, Gregory Heytings wrote: >> you've instead implemented the behavior "for" me >> > > That's not what I did, I tried to implement a function that provides > different possible behaviors corresponding to different needs and > expectations, not just the behavior you expected.  And I did this based > on your feedback, what others said on emacs-devel, and my own feelings. > I hoped (and thought until today) that the behavior you expected was one > of them. And that's fine. I have no issue supporting behaviors other than the one I personally want. (For example, I have no problem with the `empty' behavior, even though I wouldn't personally find it useful.) However, I also want to be sure that we don't provide *unnecessarily* many options here, since that adds to the maintenance burden and may produce unexpected behavior for users if they don't quite understand the distinction between each possible setting. In this case, I think it's better to continue prompting users when killing a non-last client just like Emacs 28[2] does. There might be some value in avoiding that prompt, but I think a user who *doesn't* use `server-stop-automatically' is just as likely to want that behavior, so if we want to support that, we should provide a separate configuration option to do so. In particular, I think it's valuable to prompt users in this case because it comes up when using emacsclient and committing code. If I set `EDITOR="emacsclient -c"' and run `git commit', then under Emacs 28, I can close the client with `C-x C-c'[3] and it will prompt me if I forgot to save the commit message. That's useful because without the prompt, it would (usually) just abort the commit due to an empty message. I think that behavior is worth preserving. (Likewise, I think it's worth preserving the ability to keep all your open frames by pressing C-g if Emacs prompts you about saving files when you try to kill a client.) Thus, I implemented the patch that you can see in the original message. -------------------- In addition, I'm not certain that we need both `delete-frame' (or `delete-last-frame' as it's called in your latest patch) and `kill-terminal'. The only difference between the two is that in the former, individually closing the last non-daemon frame (e.g. by `C-x 5 0' or clicking the X on the frame's titlebar) also kills the daemon. I prefer the behavior of `delete-frame', since my mental model is that the daemon should be killed *whenever* the last non-daemon frame is closed, no matter *how* it's closed. Maybe someone has a strong opinion in the other direction and actively wants the `kill-terminal' behavior instead. I don't have a problem with keeping that option around if someone would actually use it, but I'm skeptical of that. In this case though, I'm happy to present my argument and then defer to the Emacs maintainers to make the final call, whatever that may be. If it stays, that's fine with me; if it goes, that's fine too. -------------------- Since, as you mentioned before, we have different mental models for how this works, I'm mainly trying to explain through both prose and patches how this should work under my mental model. If I understand your prior messages correctly, your mental model is best encapsulated by the `empty' configuration. I'm 100% happy to keep that around as-is, even though it's not my preferred solution. However, my preferred solution is "something close to `delete-frame'". Your patch in bug#51377 gets most of the way to what I wanted, but there are a couple of corner cases that don't work like I expect, hence this bug. Whether the behavior is a true "bug", a miscommunication, or something else doesn't matter much to me. All I'm looking for is something along the following lines (note: this isn't 100% rigorous, so don't take it as a precise specification): 1) When killing a non-last client (including by closing the last of its frames), the behavior should be exactly the same as the default emacsclient behavior. (That's what this bug is about.) 2) When killing the last client (including by closing the last of its frames), the behavior should be exactly the same as killing Emacs when *not* using a server. (Roughly speaking, that means calling `save-buffers-kill-emacs'. It would also be nice to have an option to silence the "This Emacs session has clients; exit anyway?" prompt, though I can certainly understand others wanting to keep it around in this case.) Again, that may not be 100% precise, but it's the mental model I've used while implementing patches for this on my end. The specific implementation I use has shifted somewhat over time as I find corner cases, and also through consulting your patches. Using `delete-frame-functions' as in your code greatly simplified my implementation, for example. Thanks for that. Hopefully my delays in following up on bug#51377 haven't been *too* disruptive. As mentioned, I was unfortunately too busy to devote sufficient time to it back then (my plan when posting to emacs-devel was just to collect feedback and to work on the implementation slowly over the next several weeks). Now my schedule is a bit less hectic, and I'm hoping to address the last few concerns I had after taking the time to test things out more thoroughly. I'm certainly not trying to step on your toes or undo your patch. Just to account for certain corner cases that I didn't have a chance to investigate (or resolve) at the time. [1] https://lists.gnu.org/archive/html/emacs-devel/2021-10/msg01465.html [2] Or without `server-stop-automatically' [3] You could also use `C-x #' here, but I find `C-x C-c' easier to type, so prefer the latter in cases where either would do what I want.