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 10:25:19 -0800 Message-ID: <64c7eb70-d941-9c98-4513-a2bdc44e7953@gmail.com> References: <9e47c871-a2c3-d764-bec9-d87abf3efe83@gmail.com> <83pmqvti49.fsf@gnu.org> <890d44ded2b56811ceff@heytings.org> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12751"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 51993@debbugs.gnu.org To: Gregory Heytings , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 23 19:26:10 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 1mpaUc-00037a-Fo for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 23 Nov 2021 19:26:10 +0100 Original-Received: from localhost ([::1]:41558 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mpaUa-000465-Sr for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 23 Nov 2021 13:26:08 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:35542) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mpaUU-00045j-Nz for bug-gnu-emacs@gnu.org; Tue, 23 Nov 2021 13:26:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40709) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mpaUU-00038n-Fp for bug-gnu-emacs@gnu.org; Tue, 23 Nov 2021 13:26:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mpaUU-0007jW-Ak for bug-gnu-emacs@gnu.org; Tue, 23 Nov 2021 13:26: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: Tue, 23 Nov 2021 18:26: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.163769192829676 (code B ref 51993); Tue, 23 Nov 2021 18:26:02 +0000 Original-Received: (at 51993) by debbugs.gnu.org; 23 Nov 2021 18:25:28 +0000 Original-Received: from localhost ([127.0.0.1]:52255 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mpaTv-0007iZ-Ix for submit@debbugs.gnu.org; Tue, 23 Nov 2021 13:25:27 -0500 Original-Received: from mail-pj1-f45.google.com ([209.85.216.45]:46977) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mpaTs-0007iL-PR for 51993@debbugs.gnu.org; Tue, 23 Nov 2021 13:25:26 -0500 Original-Received: by mail-pj1-f45.google.com with SMTP id np6-20020a17090b4c4600b001a90b011e06so3633149pjb.5 for <51993@debbugs.gnu.org>; Tue, 23 Nov 2021 10:25:24 -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=8jYQRGQ7ImTw84ITqH6fbfWHu+8RZube9rXD6RAqWs0=; b=gpYQT7wOvCFeUNIExRsssbpuh7Xx+oZe98F3yF0RGiavi0cgua7OG6ZnzkJQlJlRM3 wexbITOCEZYQzwr3YFMux4kJwNnmjuqv17PMOvJbkRboBH7BObdkrPa47b7a6Ngy1P3E jzhgk7ZyJt4Qr8OA+I4dRlkoIOj+YVRZQtvV7wv8w720eNgB1n5d2TREPPE4RNRG7+Ih Asx+56iInGOobikBbbgy9+8doHXQzZlOmIZ2VTvCQXHMyyOJMXwY3x97/QrOI4gPR11f GlO+lG6/nETyi+qtNpuTd8Pz9n2elblJqsNMIAijedwczhhUi6jdTgAojfw2Bs8OJIz7 k75Q== 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=8jYQRGQ7ImTw84ITqH6fbfWHu+8RZube9rXD6RAqWs0=; b=zqDFJGIgB76KI/K/mOWd10ALFrMWYWJ4WiED+v99WsEdZoCUCEfWCiFaTeeYNjpgQr yDkoQxgcnJjIVLLz7YXI8JFf4sd9V+dkj0ZLA3bM/+0/YNWOhBPzJ7gUJ8ZWT14MJPz6 VFR/6qpUOJ7M/ixR/TdpPqs/xGjs7ydIcdXZFTZgBQpRZf0L1QZ6H5E58IipBPcAiQDI kDqp0YrPNi/bXEpCZo/yl0x102rW8aeZRXlf6OJZosxs1GqcmFiKd1K7WyMvPGM0f8Fl yqbPTn/FsQbfcfcH5LGZjbAoFX7X80FYlGJDlOKnHakN5DorSfST7qhdQi2jJXfcLA6W DNkQ== X-Gm-Message-State: AOAM530xpOUdguiEEzB4K6BHuNd0XbXJyMlLO/ET7DK19joPm+ArM85y QIuVJ27d7a7K/EK9kZ/CEd0= X-Google-Smtp-Source: ABdhPJxXbz3UfURmL/bLvCpcEqEw5jKjAHYo6yQRvxkInBO/GrPpp/kmcsGlmCUyJOJkvWILtNbRXw== X-Received: by 2002:a17:90b:128d:: with SMTP id fw13mr5590864pjb.50.1637691918818; Tue, 23 Nov 2021 10:25:18 -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 a12sm9335311pgg.28.2021.11.23.10.25.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Nov 2021 10:25:18 -0800 (PST) In-Reply-To: <890d44ded2b56811ceff@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:220686 Archived-At: (Cc'ing Lars since he merged the previous patch, and I want to be sure everyone's on the same page here.) On 11/23/2021 1:48 AM, Gregory Heytings wrote: > This is not a bug, this is the intented behavior of that feature, which > was discussed on emacs-devel and in bug#51377. I started that discussion[1] (and participated throughout it), and I don't think we actually agreed that this was the intended behavior. The closest I see is this: On 10/24/2021 11:08 AM, Jim Porter wrote[2]: > I don't think this is true in general. The docstring for > `server-save-buffers-kill-terminal' says: "If emacsclient was started > with a list of filenames to edit, then only these files will be asked to > be saved." As a result, some files with unsaved changes may still exist, > so we'd want to prompt about those *before* the last frame is closed. However, I should stress that the case I brought up above is just a counterexample to show a problem with a previous implementation strategy, not a full specification. That's part of why I posted patches in bug#51377 in the hopes that an implementation would explain the behavior I intend more precisely than prose. The current behavior on Emacs 29 certainly isn't what I personally intended when bringing the idea up on emacs-devel. On 11/23/2021 1:48 AM, Gregory Heytings wrote: > I attached a patch which preserves the intended behavior of that > feature, and adds a fourth possible behavior, the one Jim now wants. I'm concerned that we're now up to 4 different behaviors, when I think two of them are just the result of a miscommunication between the two of us. The way I've interpreted our prior discussion is that you would prefer the daemon to be killed invisibly if there's no reason to keep it alive; this is the `empty' option in your patches. On the other hand, I'd prefer to the daemon to be killed "loudly" when there are no non-daemon frames left, including being prompted to save buffers, kill processes, etc in all the "usual" cases; this is `delete-last-frame' in your patch, plus a couple of other tweaks I have pending. (Note: Just to be clear, this isn't a specification; it's only a brief summary.) I think your message to me in bug#51377 encapsulates this well: On 10/24/2021 2:37 PM, Gregory Heytings wrote[3]: > I see. We have different mental models, I guess. From my viewpoint > the Emacs server should stay there until it's not necessary, and I'd be > surprised to be queried about what to do with buffers opened of > processes started in a frame I already closed when I want to close > another frame. But of course I do not object to have both behaviors. However, in your next two messages in the bug, you added: On 10/26/2021 3:37 AM, Gregory Heytings wrote[4]: > If it's now also necessary to kill the daemon when you close the > last Emacs frame with the window manager close button (I did not see > this requirement in your original post)... On 10/26/2021 4:59 AM, Gregory Heytings wrote[5]: > It just occurred to me that it's very easy to add a third behavior, > namely the one you expect... (The "third behavior" is the `delete-frame' option.) As I understand things, both the `kill-terminal' and `delete-frame' options were added to support my mental model in particular (we were the only two people commenting on the bug at that time). From my perspective, `kill-terminal` (and now `kill-last-terminal' as well) are just the result of some miscommunication between the two of us in bug#51377. Unless there's a strong argument for keeping them around, I think it would be best to remove them so that there are only 2 options (well, 3 if you include the default behavior). I hope the above explains things reasonably thoroughly for everyone (hence all the citations to previous discussions). If pressed, I could probably create a full specification of the behavior I'd like to see, but I find it quite a bit easier to explain by way of a patch. If anyone needs clarification on any of the above, just let me know and I'll try to elaborate. [1] https://lists.gnu.org/archive/html/emacs-devel/2021-10/msg01465.html [2] https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg02163.html [3] https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg02207.html [4] https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg02367.html [5] https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg02373.html