[mu4e bug] New message composer doesn't close new frame on exit

[fintelkai]

Describe the bug

Previously with mu4e-compose-in-new-frame and message-kill-buffer-on-exit both set to true, the new frame that was created when composing was then deleted after sending. I assume this is because kill-buffer knew that the frame was a dedicated frame. With the new message composing code, and with mu4e-compose-switch and message-kill-buffer-on-exit both set to true, the new frame is not deleted after sending.

How to Reproduce

See above.

Environment

macOS Sonoma 14.1
GNU Emacs 30.0.50 (build 1, aarch64-apple-darwin22.5.0, NS appkit-2299.60 Version 13.4.1 (Build 22F82)) of 2023-07-03
mu/mu4e 1.11.23

Checklist

• you are running either an 1.8.x/1.10.x release or master (otherwise please upgrade)
• you can reproduce the problem without 3rd party extensions (including Doom/Evil, various extensions etc.)
• 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]

Deleting the frame is not so easy (and the old impl was a bit fragile in that), since we do not necessarily know whatever frame we are currently looking at is the frame opened for the message (you can switch buffers after all); in fact with C-x 5 m, mu4e doesn't even know that a frame was opened).

Let's see what we can do....

[fintelkai]

Thanks, yeah, I realize that the code must be fragile. I tried tracing what is happening and couldn't wrap my head around it. I applaud the idea of simplifying the mu4e code and reusing existing facilities. Maybe I'll just get used to not having a new frame.

[djcb]

Ha, well, we should be able to fix it somehow, e.g. C-c C-k seems to do the right thing.

[djcb]

I'll make a change to delete the frame if there are multiple frames and there is only one window.

[markk]

This frame deletion logic seems rather too aggressive and non-specific. I quite often have multiple frames open and was surprised to have my frame disappear on sending an email! For the moment I've overridden mu4e--maybe-delete-frame with advice, but perhaps there is a better way?

Maybe when a new frame is opened by the message composer it can be tagged in some way?

[djcb]

Yeah, it's a bit too aggressive, I'm experimenting with some ways to make it less so.

Tagging a new frame is one option I considered, but it's not really air-tight, since e.g. C-x 5 m will create a new frame that I can't easily intercept.

[j0ni]

I think I was bitten by this - even when I have just one frame, maybe because I start emacs in a shell using --daemon, this ends up killing my frame.

for now:

(advice-add 'mu4e--maybe-delete-frame
            :around (defun never-delete-frame (&rest ignore)))

[djcb]

...continued with issue #2600