Restoring window configuration after sending or quitting still broken

[thierryvolpiatto]

Describe the bug

When replying to an email or killing mail (C-c C-k), the window handling the buffer used prior starting mu4e popup.

How to Reproduce 1) M-x mu4e 2) Jump to an email (you have now two windows: One for mu4e-headers and one for article. 3) Reply to this Email 4) Send When message is sent I expect retrieve 2) but I have instead only the headers buffer and the previous buffer where I started mu4e in 1) 4bis) Hit C-c C-k, same behavior as in 4).

This is not new, I already send a related bugreport about this. I must apply a patch on top of master after each update, here the last one after rebasing my branch and resolving conflicts:

commit 94b7666e0f58a917e3fe7de2f499573ed2faa708
Author: Thierry Volpiatto <thievol@posteo.net>
Date:   Sun Jan 7 14:57:54 2024 +0100

    Restore frame config after sending email

diff --git a/mu4e/mu4e-compose.el b/mu4e/mu4e-compose.el
index 94e89a12..fa9f2df0 100644
--- a/mu4e/mu4e-compose.el
+++ b/mu4e/mu4e-compose.el
@@ -547,6 +547,20 @@ appropriate flag at the message forwarded or replied-to."
   "Function called just after sending a message."
   (setq mu4e-sent-func #'mu4e-sent-handler)
   (mu4e--server-sent (buffer-file-name)))
+
+(defun mu4e-message-kill-buffer ()
+  "Wrapper around `message-kill-buffer'.
+It attempts to restore some mu4e window layout after killing the
+compose-buffer."
+  (interactive)
+  (let ((view (save-selected-window (mu4e-get-view-buffer)))
+        (hdrs (mu4e-get-headers-buffer)))
+    (message-kill-buffer)
+    ;; try to go back to some mu window if it is live; otherwise do nothing.
+    (if (buffer-live-p view)
+        (switch-to-buffer view)
+      (when (and (buffer-live-p hdrs))
+        (switch-to-buffer hdrs)))))
 
 ;;; Crypto
 (defun mu4e--compose-setup-crypto (parent compose-type)
@@ -610,7 +624,7 @@ buffers; lets remap its faces so it uses the ones for mu4e."
     (define-key map (kbd "C-S-u")    #'mu4e-update-mail-and-index)
     (define-key map (kbd "C-c C-u")  #'mu4e-update-mail-and-index)
     (define-key map (kbd "C-c ;")    #'mu4e-compose-context-switch)
-
+    (define-key map (kbd "C-c C-k")  #'mu4e-message-kill-buffer)
     ;; emacs 29
     ;;(keymap-set map "<remap> <beginning-of-buffer>" #'mu4e-compose-goto-top)
     ;;(keymap-set map "<remap> <end-of-buffer>" #'mu4e-compose-goto-bottom)
@@ -852,6 +866,11 @@ replied to or forwarded, etc."
   (set-buffer-modified-p nil)
   (undo-boundary))

+;; FIXME: Something is already trying to restore the underlaying windows/frames
+;; that were here before starting composing Mail but fails to do so.  As a
+;; workaround we save the frame config before composing and then restore it
+;; through `message-send-actions' but a better fix would be to fix previous
+;; attempt to restore initial window/frame config.
 (defun mu4e--compose-setup (compose-type compose-func &optional switch)
   "Set up a new buffer for mu4e message composition.

@@ -873,28 +892,22 @@ Returns the new buffer."
             (mu4e-message-at-point)))
          (mu4e-compose-parent-message parent)
          (mu4e-compose-type compose-type)
-         (oldframe (selected-frame)))
+         (winconf (current-frame-configuration))
+         (restore-winconf (lambda () (set-frame-configuration winconf)))
+         (actions (append (list restore-winconf) message-send-actions))
+         (buf (mu4e--compose-setup-buffer compose-type compose-func parent)))
     (advice-add 'message-is-yours-p :around #'mu4e--message-is-yours-p)
     (run-hooks 'mu4e-compose-pre-hook) ;; run the pre-hook. Still useful?
     (mu4e--context-autoswitch parent mu4e-compose-context-policy)
-    (with-current-buffer
-        (mu4e--compose-setup-buffer compose-type compose-func parent)
+    (with-current-buffer buf
+      (funcall (or switch (mu4e--compose-switch-function)) (current-buffer))
       (unless (eq compose-type 'edit)
         (set-visited-file-name ;; make it a draft file
          (mu4e--draft-message-path (mu4e--message-basename) parent)))
       (mu4e--compose-setup-post compose-type parent)
-      (funcall (or switch (mu4e--compose-switch-function)) (current-buffer))
-      (let* ((msgframe (selected-frame))
-             (actions (list
-                       (lambda () ;; kill frame when it was created for this
-                         (unless (eq oldframe msgframe)
-                           (delete-frame msgframe))))))
-        ;; handle closing of frames.
-        (setq-local ;;message-kill-actions actions
-         message-return-actions actions
-         message-send-actions actions
-         message-kill-actions actions))
-      (current-buffer))))
+      ;; handle closing of frames.
+      (setq-local message-send-actions actions))
+    (switch-to-buffer buf)))

 
 ;;;###autoload
@@ -1012,7 +1025,7 @@ The message is resent as-is, without any editing."
 (define-mail-user-agent 'mu4e-user-agent
   #'mu4e-compose-mail
   #'message-send-and-exit
-  #'message-kill-buffer
+  nil
   'message-send-hook)

 ;; Without this, `mail-user-agent' cannot be set to `mu4e-user-agent'

Environment Please describe the versions of OS, Emacs, mu/mu4e etc. you are using. LinuxMint, Emacs-29.3

Checklist

• [X ] you are running either an 1.8.x/1.10.x release or master (otherwise please upgrade)
• [ X] you can reproduce the problem without 3rd party extensions (including Doom/Evil, various extensions etc.)
• [ X] you have read all of the above

Please make sure you all items in the checklist are set/met before filing the ticket. Thank you!

[djcb]

We have #2600 already for this, well, imperfection, no need for a second ticket for that. Trying to restore an older window setup is imperfect in itself, as it may be outdated by the time we try to apply it.

[thierryvolpiatto]

"Dirk-Jan C. Binnema" @.***> writes:

1. ( ) text/plain (*) text/html

We have #2600 already for this, well, imperfection, no need for a second ticket for that. Trying to restore an older window setup is imperfect in itself, as it may be outdated by the time we try to apply it.

Sure, but while I don't find something better, it is better than nothing.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.*Message ID: @.***>

-- Thierry

[djcb]

It works better for me now, at least I can't repro the one prob mentioned in #2600. Anyway, no need for this dup ticket, closing.