bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#65277: 29.1.50; emacsclient Dired: frame is closed/killed when openi


From: Eli Zaretskii
Subject: bug#65277: 29.1.50; emacsclient Dired: frame is closed/killed when opening another dir
Date: Thu, 17 Aug 2023 12:44:47 +0300

> From: brickviking <brickviking@gmail.com>
> Date: Wed, 16 Aug 2023 18:37:59 +1200
> 
> Further to the above tests from me which were in graphics mode, I also did 
> the same test with
> textmode as follows:
> 
> shell1$ emacs -Q  # in graphics mode
> A frame renders, I then start up the server:
>    M-x server-start
> 
> That frame stays around.  Going off to another shell, I started an 
> emacsclient, but this time in text
> mode.
> 
>    shell2$ emacsclient -t GNUmakefile
> 
> The terminal is cleared, and the contents of GNUmakefile appear. A buffer is 
> assigned, as I can tell in
> C-x C-b in the original server window.
> 
> In the minibuffer (of the emacsclient) I then go:
>   C-x C-v INSTALL
> and the terminal returns to the shell prompt. Interestingly, the contents of 
> INSTALL then appear in the
> original emacs server window, and in the buffer listing, GNUmakefile has been 
> replaced by INSTALL
> when I refresh the buffer listing.
> 
> My conclusion is that this bug hasn't exactly been "fixed" with the patches 
> to files.el and server.el, but
> at least in graphics mode the frame hangs around instead of the content 
> turning up in the parent
> frame with the server running.

Thanks for testing.  Could you please test the improved patch below?
It includes the original changes you already tested, so please use it
to patch the original files.el and server.el, not the versions already
patched by the changes I sent earlier.

diff --git a/lisp/files.el b/lisp/files.el
index 68c0a10..cc17445 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -1998,6 +1998,8 @@ kill-buffer-hook
 Note: Be careful with let-binding this hook considering it is
 frequently used for cleanup.")
 
+(defvar find-alternate-file-dont-kill-client nil
+  "If non-nil, `server-buffer-done' should not delete the client.")
 (defun find-alternate-file (filename &optional wildcards)
   "Find file FILENAME, select its buffer, kill previous buffer.
 If the current buffer now contains an empty file that you just visited
@@ -2044,7 +2046,8 @@ find-alternate-file
     ;; save a modified buffer visiting a file.  Rather, `kill-buffer'
     ;; asks that itself.  Thus, there's no need to temporarily do
     ;; `(set-buffer-modified-p nil)' before running this hook.
-    (run-hooks 'kill-buffer-hook)
+    (let ((find-alternate-file-dont-kill-client t))
+      (run-hooks 'kill-buffer-hook))
     ;; Okay, now we can end-of-life the old buffer.
     (if (get-buffer " **lose**")
        (kill-buffer " **lose**"))
diff --git a/lisp/server.el b/lisp/server.el
index ba7e02d..e616d59 100644
--- a/lisp/server.el
+++ b/lisp/server.el
@@ -372,6 +372,10 @@ server-delete-client
       ;; console), where there's only one terminal and does not make
       ;; sense to delete it, or if we are explicitly told not.
       (unless (or (eq system-type 'windows-nt)
+                  ;; 'find-alternate-file' caused the last client
+                  ;; buffer to be killed, but we will reuse the client
+                  ;; for another buffer.
+                  (eq noframe 'find-alternate-file-dont-kill-client)
                   (process-get proc 'no-delete-terminal))
        (let ((terminal (process-get proc 'terminal)))
          ;; Only delete the terminal if it is non-nil.
@@ -1590,7 +1594,8 @@ server-buffer-done
                ;; frames, which might change the current buffer.  We
                ;; don't want that (bug#640).
                (save-current-buffer
-                 (server-delete-client proc))
+                 (server-delete-client proc
+                                        find-alternate-file-dont-kill-client))
              (server-delete-client proc))))))
     (when (and (bufferp buffer) (buffer-name buffer))
       ;; We may or may not kill this buffer;





reply via email to

[Prev in Thread] Current Thread [Next in Thread]