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

Previous Next

To reply to this bug, email your comments to 77276 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: "Jay Berkenbilt" <ejb <at> ql.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.1; find-alternate-file no longer disconnects emacsclient
Date: Wed, 26 Mar 2025 07:43:42 -0400

[Message part 1 (text/plain, inline)]

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.

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.

Generated information below.

In GNU Emacs 30.1 (build 1, aarch64-apple-darwin21.6.0, NS
appkit-2113.65 Version 12.7.6 (Build 21H1320)) of 2025-02-24 built on
armbob.lan
Windowing system distributor 'Apple', version 10.3.2575
System Description:  macOS 15.3.2

Configured using:
'configure --with-ns '--enable-locallisppath=/Library/Application
Support/Emacs/${version}/site-lisp:/Library/Application
Support/Emacs/site-lisp' --with-modules 'CFLAGS=-DFD_SETSIZE=10000
-DDARWIN_UNLIMITED_SELECT' --with-x-toolkit=no'

Configured features:
ACL GLIB GMP GNUTLS JPEG LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER PNG
RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Terraform

Minor modes in effect:
  terraform-format-on-save-mode: t
  server-mode: t
  global-visual-wrap-prefix-mode: t
  visual-wrap-prefix-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  column-number-mode: t
  line-number-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/Users/ejb/.emacs.d/elpa/editorconfig-20240604.602/editorconfig hides /Applications/Emacs.app/Contents/Resources/lisp/editorconfig <http://emacs.app/Contents/Resources/lisp/editorconfig>
/Users/ejb/.emacs.d/elpa/editorconfig-20240604.602/editorconfig-core hides /Applications/Emacs.app/Contents/Resources/lisp/editorconfig-core <http://emacs.app/Contents/Resources/lisp/editorconfig-core>
/Users/ejb/.emacs.d/elpa/editorconfig-20240604.602/editorconfig-conf-mode hides /Applications/Emacs.app/Contents/Resources/lisp/editorconfig-conf-mode <http://emacs.app/Contents/Resources/lisp/editorconfig-conf-mode>
/Users/ejb/elisp/startup hides /Applications/Emacs.app/Contents/Resources/lisp/startup <http://emacs.app/Contents/Resources/lisp/startup>
/Users/ejb/.emacs.d/elpa/editorconfig-20240604.602/editorconfig-tools hides /Applications/Emacs.app/Contents/Resources/lisp/editorconfig-tools <http://emacs.app/Contents/Resources/lisp/editorconfig-tools>
/Users/ejb/.emacs.d/elpa/editorconfig-20240604.602/editorconfig-core-handle hides /Applications/Emacs.app/Contents/Resources/lisp/editorconfig-core-handle <http://emacs.app/Contents/Resources/lisp/editorconfig-core-handle>
/Users/ejb/.emacs.d/elpa/editorconfig-20240604.602/editorconfig-fnmatch hides /Applications/Emacs.app/Contents/Resources/lisp/editorconfig-fnmatch <http://emacs.app/Contents/Resources/lisp/editorconfig-fnmatch>

Features:
(shadow sort flyspell ispell mail-extr warnings emacsbug imenu
terraform-mode dash hcl-mode shell pcomplete yaml-mode misearch
multi-isearch vc-git diff-mode track-changes easy-mmode markdown-mode
color thingatpt noutline outline cap-words superword subword
use-package-ensure cl-extra help-mode use-package-core vc-svn vc
vc-dispatcher qmime qmime-compose qmime-view filecache server
compile-eslint rx compile ange-ftp comint ansi-osc ansi-color ring
message sendmail yank-media puny dired dired-loaddefs rfc822 mml mml-sec
epa derived epg rfc6068 epg-config gnus-util text-property-search
time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047
rfc2045 mm-util ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils
mailheader cc-styles cc-align cc-engine cc-vars cc-defs jka-compr
visual-wrap cus-load advice ahk-mode-autoloads cmake-mode-autoloads
company-autoloads dockerfile-mode-autoloads
flycheck-golangci-lint-autoloads flymake-go-staticcheck-autoloads
go-mode-autoloads groovy-mode-autoloads jinja2-mode-autoloads
json-mode-autoloads kotlin-mode-autoloads lsp-mode-autoloads
ht-autoloads lua-mode-autoloads lv-autoloads markdown-mode-autoloads
mermaid-mode-autoloads prettier-autoloads editorconfig-autoloads
nvm-autoloads f-autoloads iter2-autoloads rust-mode-autoloads
spinner-autoloads terraform-mode-autoloads hcl-mode-autoloads
tide-autoloads flycheck-autoloads s-autoloads info dash-autoloads
typescript-mode-autoloads web-mode-autoloads xterm-color-autoloads
yaml-mode-autoloads package browse-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie generate-lisp-file
url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq
eieio eieio-core cl-macs icons password-cache json subr-x map byte-opt
gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl
tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/ns-win ns-win ucs-normalize
mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads kqueue cocoa ns multi-tty make-network-process emacs)

Memory information:
((conses 16 153394 31179) (symbols 48 15524 0) (strings 32 44243 2071)
(string-bytes 1 1173627) (vectors 16 23749)
(vector-slots 8 232341 13472) (floats 8 195 122)
(intervals 56 1844 55) (buffers 992 17))

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Jay Berkenbilt" <ejb <at> ql.org>
Cc: 77276 <at> debbugs.gnu.org
Subject: Re: bug#77276: 30.1;
 find-alternate-file no longer disconnects emacsclient
Date: Wed, 26 Mar 2025 15:02:38 +0200

> 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.

> 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.

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.