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#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an emacsclient doesn't ask to save Date: Tue, 1 Nov 2022 09:11:40 -0700 Message-ID: References: <9a70f868-ca50-52fc-af3e-23813af104f2@gmail.com> <83zgdcduxm.fsf@gnu.org> <53238b5b-3e0a-3dfe-eeba-f37cafa81f50@gmail.com> <838rkveq3n.fsf@gnu.org> <7de45884-b4c9-4a4c-777c-5db17b3bacca@gmail.com> <835yfzeobt.fsf@gnu.org> <7694fcf2-8982-9099-5eb8-39835d049847@gmail.com> <83y1svch5u.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6742"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 58909@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 01 18:12:33 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 1opuoT-0001ZH-8y for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Nov 2022 18:12:33 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1optrv-0003Df-Qa; Tue, 01 Nov 2022 12:12:03 -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 1optru-0003DY-K9 for bug-gnu-emacs@gnu.org; Tue, 01 Nov 2022 12:12:02 -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 1optru-0001YC-Cu for bug-gnu-emacs@gnu.org; Tue, 01 Nov 2022 12:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1optru-0000Hx-06 for bug-gnu-emacs@gnu.org; Tue, 01 Nov 2022 12:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jim Porter Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Nov 2022 16:12: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.16673191101088 (code B ref 58909); Tue, 01 Nov 2022 16:12:01 +0000 Original-Received: (at 58909) by debbugs.gnu.org; 1 Nov 2022 16:11:50 +0000 Original-Received: from localhost ([127.0.0.1]:44067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1optrh-0000HU-Eb for submit@debbugs.gnu.org; Tue, 01 Nov 2022 12:11:49 -0400 Original-Received: from mail-pf1-f178.google.com ([209.85.210.178]:40866) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1optrf-0000HG-Ac for 58909@debbugs.gnu.org; Tue, 01 Nov 2022 12:11:47 -0400 Original-Received: by mail-pf1-f178.google.com with SMTP id y13so13880443pfp.7 for <58909@debbugs.gnu.org>; Tue, 01 Nov 2022 09:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=utqA4ISbWGl45yR/IPhYCYfp1heNQLwY17UMC4oTTj0=; b=NndV+GTAYAplRmjx5kJlm22tbqUb/kexg7gnCPlFFVsB6TwTnmnIKVYW3ECwkqn8SB nDVDa4LmRIIMFHmWp8Ga+Z+fP8HycSuXcB/EZI90iG0vGvgScj+0zxE2OJF//jlTKxPB T7wS/d5KEzeS8Pq2BKX2LIUcVJQabGw0/3uv7CG1L6dq8c6skOlf0de2Xoz0B7x59Nn5 s7LlsDys4VLnF/uAl1DGvypmCS5FHB/AP4cdB2fFWiAWOjqXqUmwPlWqeeshlalUVcBX +w1xLqbsPd5cixlbWIlomfmI6v5eeBXRUNnwS0m5GDTjMe6pgOB2n9OaaxXc4wVHRmsr U6gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=utqA4ISbWGl45yR/IPhYCYfp1heNQLwY17UMC4oTTj0=; b=C0kl1185SYHnKMh+/btbw9jIQPkMdpDcI+8q4XrSXaBtvHBZsXgHpdeOJyIL/Cv/v6 o+nfwXLFs8YNIOpwn/6UEJVAFl/FVnVYDW8WTa67NtfNdg+QjCYwP2hDpLHegGd5E6Zx 9nC+Hh9By9V3EPHar6jWu5hJmx2yTI9OGOncud1oQy3jkBWlaPOwl9np9Uv8uchHzTo1 q/MOFrqA6Db36ELmG4CkMZeMyoT1iXS+lbizZj9t1M0SRNMM+oXthATK20dvAubQ4A0i vRLZv4ejNxW0PI7YdYGs2X51RhyEsbEpM41xQEbfNPUcf9TO+qkpBNzB+th7S4HAT1FX 93wQ== X-Gm-Message-State: ACrzQf0kE20UOLg57XKTFcHXcVIVfIZjid01Z+7CzM1mJZPpC5+1xgEB S9qDLbBUBZR0TOP/aiPA7FfMWnWumw8= X-Google-Smtp-Source: AMsMyM5R+a8MY0hMr8I036AQqF+20mDhmEfqV2yIGEkiMEXmU44MX7AkQXcWYtUqRHnkHBbtV8JfNw== X-Received: by 2002:a63:7252:0:b0:46f:9763:7355 with SMTP id c18-20020a637252000000b0046f97637355mr14090383pgn.542.1667319101428; Tue, 01 Nov 2022 09:11:41 -0700 (PDT) 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 m12-20020a170902db0c00b0018725c2fc46sm3604399plx.303.2022.11.01.09.11.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Nov 2022 09:11:40 -0700 (PDT) Content-Language: en-US In-Reply-To: <83y1svch5u.fsf@gnu.org> 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@gnu.org Xref: news.gmane.io gmane.emacs.bugs:246783 Archived-At: On 10/31/2022 11:39 PM, Eli Zaretskii wrote: >> Date: Mon, 31 Oct 2022 14:06:16 -0700 >> Cc: 58909@debbugs.gnu.org >> From: Jim Porter >> >> 1) For now, just make the change in my patch to 'delete-frame' in >> src/frame.c to allow hooks in 'delete-frame-functions' to quit out of >> frame deletion. That way, users who want the rest of the behavior in my >> patch can just replace 'server-handle-delete-frame' with their own Elisp >> function. This change isn't entirely without risk, since it could cause >> some hooks to go from silently signaling an error to making it >> impossible to delete frames, but I'm not sure that will come up in >> practice (and if it does, the hooks can be fixed easily enough). > > I don't see how this would serve well the use case you want to enable. > We are talking about prompting the user to save unsaved buffers, yes? > So adding a hook in server-delete-client sounds like a much better > solution to me, as it doesn't affect the (much more general) > delete-frame in any way. I think a hook on 'server-delete-client' could work well. It'd make it easier to write hooks that run at the right time compared to using other existing hooks. In fact, I had a similar idea for bug#51993[1]. In that case I ended up adding 2 hooks to 'server-delete-client', but that was just to work around a strange bug I saw in testing; I could probably fix that in a better way with some more effort so that we only need one new hook. However, I'm not sure how to do this in a complete way without tweaking 'delete-frame-functions'. Deleting a frame can cause Emacs to delete the client if that was the last frame for the client; that's long-established behavior, so we shouldn't change it. But that poses a problem. If 1) I delete a frame, 2) it calls 'server-delete-client', and 3) some 'server-delete-client-hook' prompts me, then I might try to quit out via C-g. Without my change to how 'delete-frame-functions' are run, then C-g would only quit out of 'server-delete-client', but would still delete the frame. At least for some emacsclient use cases, that could be a problem. For example, suppose I have a system called "remotehost" with an "emacs --daemon" instance and EDITOR="emacsclient -c": me@localhost $ ssh -X remotehost ... me@remotehost $ git commit ;; emacsclient starts and creates a new frame on my local display. ;; Start editing the git commit message. ;; Get distracted, do some other stuff... ;; ... finish up the other stuff, click "X" on the emacsclient frame. Save file /home/me/src/project/.git/COMMIT_EDITMSG? ;; Realize, "Oh yeah! I forgot to finish this commit message." C-g Without the 'delete-frame-functions' change, I'd now be left with no Emacs frames on my localhost, but the emacsclient is still running. That would be inconvenient, since I'd have to do more work to fix the situation. The best way I can think of would be to start another emacsclient locally, do the edits to COMMIT_EDITMSG, and then 'C-x #' to finish editing. It'd be a lot nicer if 'C-g' stopped the frame from getting deleted. (Incidentally, that's how it would work in a regular, non-client/server Emacs. Clicking "X" on the last frame actually calls 'save-buffer-kill-emacs' instead of 'delete-frame', and you can 'C-g' out of that to keep the frame open.) > You can start the discussion now, from my POV. But if having a hook > in server-delete-client is good enough, I don't see why we would need > to discuss an actual behavior change. Yeah, let's finish up the discussion here, and if I have any open questions that could use a wider audience, I'll post to emacs-devel afterwards. [1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-10/msg00908.html