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 14:08:05 -0800 Message-ID: <1623621b-d2a6-a68c-ac28-cdd371886b11@gmail.com> 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> 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="2390"; 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 Tue Nov 23 23:09: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 1mpdyQ-0000PJ-Bi for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 23 Nov 2021 23:09:10 +0100 Original-Received: from localhost ([::1]:44402 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mpdyO-0007R8-JN for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 23 Nov 2021 17:09:08 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:55918) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mpdyI-0007Qk-D6 for bug-gnu-emacs@gnu.org; Tue, 23 Nov 2021 17:09:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40880) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mpdyI-000745-2Y for bug-gnu-emacs@gnu.org; Tue, 23 Nov 2021 17:09:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mpdyH-0007lq-Im for bug-gnu-emacs@gnu.org; Tue, 23 Nov 2021 17:09:01 -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 22:09:01 +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.163770529529806 (code B ref 51993); Tue, 23 Nov 2021 22:09:01 +0000 Original-Received: (at 51993) by debbugs.gnu.org; 23 Nov 2021 22:08:15 +0000 Original-Received: from localhost ([127.0.0.1]:52426 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mpdxX-0007kf-CJ for submit@debbugs.gnu.org; Tue, 23 Nov 2021 17:08:15 -0500 Original-Received: from mail-pf1-f170.google.com ([209.85.210.170]:46730) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mpdxV-0007kO-4O for 51993@debbugs.gnu.org; Tue, 23 Nov 2021 17:08:13 -0500 Original-Received: by mail-pf1-f170.google.com with SMTP id o4so595677pfp.13 for <51993@debbugs.gnu.org>; Tue, 23 Nov 2021 14:08:13 -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=ByiTuqy4zaXIHUWAxwSNnYzxRs9+PcPl/HMC1u3V2/U=; b=n9TaSxgB3UG+N+EHU0uqVEwsTPo2UW24IlIdTotuXBR4C0jZXhFVpRfAub14ZtZ6Qu Po1whVJplvbS9+5A8FOrKJ0VPrBw19I1rIVShyQwA1EcezHHmf6essFDUM+65jT61CUS UfDG6DNeWxfUGIVSsS+eDg8lVWcVOfaeV6l5YaUXlmGpSzoFaho+zficjPGvlIsqz044 hPiPN+61R/6ZXT2PPPwqMbtVp8pTHpByfSvaSWchQjPEWlXjqGZIbRV0Vq1ZckVTaU8+ l6a9BLBNPIjgcs+gO4rCb2URXUaOkmyI2T+jsNDhq7CWVJ/WNWd0XbSigbpChs/aiDMQ cCXw== 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=ByiTuqy4zaXIHUWAxwSNnYzxRs9+PcPl/HMC1u3V2/U=; b=JftQ+3xNon62QJBjGxthhxwBCtMV4kUeGRL8uh/fS86nVVxDeG4MKw1IYBtance7/o /w6IFg0TVI0NXONokbyxPWBSxPTY19RPHth8vz9rwvssioYSq+9BkI1TfBjUe+SGoo4L gg/x6deW+tGa/4w2JepxjcdKxK2kzBOawE8U4gNNwe9Qj0VKxtVZm1Owh7n3ygrCJxA3 +Zsl0UV18tGlwTssEte0K8JoWJTMCXZOLQ+/N4TA/n+S//hUqWL+vLVhE/FVkkwAjvsS TgijyDfcvJ7OcL+LzlXFxhK+pxyej4S8GdSeG5skwtJxCRX2wJiB8TlmagZpQfPLx0Pc j3hw== X-Gm-Message-State: AOAM530zLFrNWzURV52EOac+06vKKHLtlrQ6ERfCdtuM9IaSvCYxYeTH 05UF7OMVg8y30mi8WWULYLo= X-Google-Smtp-Source: ABdhPJzLUgZC/fW8GfhDNKxIudIvSn6CIUk8rbtfIgVuY0BvdXVtBFuHVKX9O3mvEEkKL74yhQ1aiQ== X-Received: by 2002:a05:6a00:140c:b0:447:96be:2ade with SMTP id l12-20020a056a00140c00b0044796be2ademr820363pfu.26.1637705287271; Tue, 23 Nov 2021 14:08:07 -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 c10sm6431399pgk.84.2021.11.23.14.08.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Nov 2021 14:08:06 -0800 (PST) In-Reply-To: <890d44ded2fa8ff77ab2@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:220690 Archived-At: On 11/23/2021 12:37 PM, Gregory Heytings wrote: > >>> This is not a bug, this is the intented behavior of that feature >> >> I started that discussion (and participated throughout it), and I >> don't think we actually agreed that this was the intended behavior. >> > > This is the behavior I intended (and described in the docstring and > manual), if you prefer.  And you did not make further comments in > bug#51377, which can be interpreted as a kind of agreement. Unfortunately, I was sidetracked by other things and didn't have a chance to comment before Lars merged the patch. Since it had already been merged, I thought it best to follow up in a separate bug once I had made concise steps to reproduce the issue and a patch to fix it. >> I should stress that the case I brought up above is just a >> counterexample to show a problem with a previous implementation strategy >> > > Which problem? Prior to that comment, your proposed implementation would kill Emacs on a timer when there were no non-daemon frames left, which could result in unsaved changes to files being lost. I replied to point that out and showed some steps to reproduce it: . >> The current behavior on Emacs 29 certainly isn't what I personally >> intended when bringing the idea up on emacs-devel. >> > > Is the current behavior of Emacs 29 with my patch and > (server-stop-automatically 'kill-terminal) still not what you want?  If > not, what is missing? If I'm understanding your patch, the behavior I'm looking for is essentially a combination of `kill-terminal' and `delete-last-frame'. I may be misunderstanding it though, since the call tree in your patch confuses me a bit: with `kill-terminal', `server-save-buffers-kill-terminal` calls `server-stop-automatically--handle-delete-frame', which then calls `server-save-buffers-kill-terminal' again. One of my other goals in my patch was to simplify the logic in `server-save-buffers-kill-terminal' and `server-stop-automatically--handle-delete-frame' somewhat. Rather than to have `server-stop-automatically--handle-delete-frame' check if it was called by `save-buffers-kill-terminal', I found that the implementation was simpler (to me, anyway) if that logic was lifted up into `server-save-buffers-kill-terminal'. One benefit of this simplification is that it causes fewer changes in behavior compared to not using `server-stop-automatically'. For example, normally when a user kills an emacsclient terminal, Emacs will prompt about saving files *before* deleting any frames. This is nice because it allows the user to back out by pressing C-g, leaving Emacs in (almost) the same state it was previously. My patch handles that and allows the user to press C-g and leave all the current frames open. With your patch in this bug, using `kill-terminal' and pressing C-x C-c will close all frames for the current client but the current one, and only then prompt the user to save buffers. Thus, pressing C-g will leave the user with only that last client frame still open. (Note: to test this behavior, you probably need multiple clients open as I outlined in the first post to this bug.) >> 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. > > They are not, AFAICS.  The four behaviors are four reasonable options, > each of which can (and is) described in a short paragraph, and > corresponds to a different user preference.  I see no reason to remove > any of the current three behaviors because of an unspecified "problem". > Especially given that all these behaviors are implemented in only ~50 > lines of Lisp. I've specified the problems. I can try to clarify if there's any confusion though. This bug is one such problem. I don't think that a user who opts in to stopping the Emacs daemon automatically is *also* opting in to changing the behavior of whether Emacs will prompt about saving files when killing a (non-last) client. Since there are other clients, the daemon won't be killed, and so the behavior should be identical to what happens without `server-stop-automatically'. As a user, I would find it very strange that enabling `server-stop-automatically' would change Emacs' behavior in ways *other than* stopping the server in certain cases. Of course, a user may indeed want to be able to kill a client (but not the daemon) without being prompted to save files, but I think that's independent of whether the daemon should be stopped when the last client exits. If users *do* want this behavior, we could add a totally separate option for it; this would allow users who don't want to be prompted but also don't want `server-stop-automatically' to use it.