GNU bug report logs - #77276
30.1; find-alternate-file no longer disconnects emacsclient

Previous Next

Full log

Message #11 received at 77276 <at> debbugs.gnu.org (full text, mbox):

From: "Jay Berkenbilt" <ejb <at> ql.org>
To: 77276 <at> debbugs.gnu.org
Subject: Re: bug#77276: 30.1;
 find-alternate-file no longer disconnects emacsclient
Date: Wed, 26 Mar 2025 14:19:10 -0400

On Wed, Mar 26, 2025, at 9:02 AM, Eli Zaretskii wrote:
> > Date: Wed, 26 Mar 2025 07:43:42 -0400
> > From:  "Jay Berkenbilt" via "Bug reports for GNU Emacs,
> >  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> > 
> > The issue I'm describing occurs in emacs 30 but not emacs 29 or earlier. I noticed it in during emacs 30.0.93
> > but didn't immediately recognize it as a bug. You can see the generated information below, but I have also
> > reproduced this on macOS with emacs -Q, and it also happens on my Linux system (with emacs -Q) where I
> > build emacs myself, so I don't believe this is environment-specific.
> > 
> > When you run emacsclient to open a file in an existing emacs, and then run M-x find-alternate-file on the
> > same file (e.g., C-x C-v RET), the file loses its connection with emacsclient, but emacsclient does not exit. In
> > prior versions, emacsclient would exit after C-x C-v RET.
> > 
> > emacs 30:
> > shell% emacsclient /tmp/a
> > emacs: C-x C-v RET    ;; emacsclient is still waiting
> > emacs: C-x #   ;; nothing happens; the buffer is no longer connected with emacsclient
> > 
> > emacs 29 and earlier:
> > shell% emacsclient /tmp/a
> > emacs: C-x C-v RET    ;; emacsclient exits
> > emacs: C-x #   ;; nothing happens; the buffer is no longer connected with emacsclient
> > 
> > Explicitly killing the buffer with C-x k does cause emacsclient to exit.
> > 
> > This is probably related to a change in find-alternate-file as the problem occurs with emacs 30 and
> > emacsclient from emacs 29 but not with emacs 29 and emacsclient from emacs 30.
> 
> This was a deliberate change, see bug#65277.  The previous behavior
> was surprising at least, if not a simple bug.

Reading through that bug, it looks like the intention was that
emacsclient _should_ exit with find-alternate-file, and there was a
lot of back and forth with various patches. In the end, perhaps the
original issue was addressed, but it looks like the problem of
find-alternate-file leaving emacsclient still running but C-x # not
doing anything persists. This was even noted in an earlier stage of
the patching in that issue and acknowledged as a problem, if I'm
reading it right.

I'm not suggesting that we should revert to some earlier behavior, but
I think perhaps the bug wasn't fixed correctly and had this unintended
side effect.

I haven't studied the patches in detail, so I may be wrong about the
sequence of events, but it does appear that the discussion
acknowledges a running emacsclient with C-x # not doing anything as a
problem. I think either emacsclient should exit, or the newly found
file should replace the old one and C-x # should cause that to go
away, but I think that would be counterintuitive.

I find the new behavior to be surprising and a departure from how it's
always worked (as I believe you actually pointed out), but I also see
it as an unintended consequence of a different fix.
 
> > I consider the older behavior to be more desirable and less surprising as emacsclient shouldn't hang around
> > waiting for an event that will never occur. In both emacs 29 and 30, CTRL-c on emacsclient will cause the
> > buffer to be removed from emacs before but not after C-x C-v, which I consider to be correct/expected
> > behavior. The fact that CTRL-c on emacsclient after C-x C-v leaves the buffer alone also shows that
> > emacsclient is no longer connected to the file in emacs 30 after C-x C-v. Note that explicitly killing the buffer
> > with C-x k still causes emacsclient to exit.
> > 
> > I have been using this technique since the dawn of time, perhaps as long as I've been using emacsclient
> > (which probably goes back to emacs 18 for me) to intentionally disconnect a file from emacsclient. I'm not
> > sure whether there's a better way. I'm trying to retrain my muscle memory to emacsclient -n, but this change
> > of behavior has made me realize how deeply this is ingrained into my habits. Anyway, it's not uncommon for
> > me to do something like `emacsclient *.tf` and then flip through the files doing C-x # on the ones I don't want
> > and C-x C-v RET on the ones I do.
> 
> I don't think we should go back to previous behavior, but we might
> have a user option to get that old behavior back.

If the old behavior includes the original problem of a frame
unexpectedly disappearing, then maybe not. Perhaps we should focus
just on eliminated this specific behavior of emacsclient sitting
around waiting for something that is never going to happen. My $0.02.

Thanks as always for the quick response.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.