From: rameiko87@posteo.net
To: Eli Zaretskii <eliz@gnu.org>
Cc: 69738@debbugs.gnu.org
Subject: bug#69738: Followup
Date: Sun, 14 Apr 2024 17:47:06 +0000 [thread overview]
Message-ID: <cd1101bc38cb3f72699bda6b8d07905a@posteo.net> (raw)
In-Reply-To: <86bk6bnbzl.fsf@gnu.org>
Dear Eli,
To answer your question: your patch doesn't work, and the reason is that
I have Rmail on frame #6 and Elfeed on frame #3. Rmail-reply creates
frame #42, from which both C-x 5 0 and C-x 5 o land on frame #27. C-u -
C-x 5 o goes from #42 to #3, and also from #27 to #3 after #42 was
deleted.
As for the current code for GUI, I can't understand why it _works_ since
the same exact problem should arise. I never used the GUI but I would
expect that it actually doesn't work for GUI either, for the same
reasons above. I think the design of Emacs makes the order of frames
rigid, so every new frame can be arbitrarily far from the original Rmail
frame.
One way is to remember the frame where Rmail was and revert back to that
one after deleting the reply frame.
On 14.04.2024 18:30, Eli Zaretskii wrote:
>> Why not just remove the condition of (display-multi-frame-p)? It's
>> neater, and I can't see any drawbacks compared to your patch (but the
>> fact that your code insists on switching to other before deleting the
>> frame makes me think there must be some reason...?)
>
> Yes, I have my reasons: I'd like to make sure we switch to the exact
> frame the user wants -- the one showing the Rmail buffer. Unlike on
> GUI displays, only a single frame is shown on a TTY, so if we
> accidentally switch to the wrong frame, the user will not see the
> frame they need, something that does happen on GUI terminals.
>
> Does the patch as I sent it work for you? If not, please tell what
> doesn't work.
next prev parent reply other threads:[~2024-04-14 17:47 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-11 22:49 bug#69738: [BUG] rmail-mail-new-frame doesn't delete the new frame after composing the message on Emacs 29.2 rameiko87
2024-03-12 13:54 ` Eli Zaretskii
2024-03-21 8:57 ` Eli Zaretskii
2024-04-13 17:44 ` bug#69738: Followup rameiko87
2024-04-14 9:44 ` Eli Zaretskii
2024-04-14 16:14 ` rameiko87
2024-04-14 16:30 ` Eli Zaretskii
2024-04-14 17:47 ` rameiko87 [this message]
2024-04-14 17:55 ` rameiko87
2024-04-14 18:50 ` Eli Zaretskii
2024-04-14 18:49 ` Eli Zaretskii
2024-04-15 10:15 ` rameiko87
2024-04-20 11:11 ` Eli Zaretskii
2024-05-04 9:37 ` Eli Zaretskii
2024-05-06 19:12 ` rameiko87
2024-05-12 22:42 ` rameiko87
2024-05-13 10:53 ` Eli Zaretskii
2024-05-28 13:28 ` rameiko87
2024-06-20 9:58 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cd1101bc38cb3f72699bda6b8d07905a@posteo.net \
--to=rameiko87@posteo.net \
--cc=69738@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).