bug#69738: Followup

[rameiko87@posteo.net]

Actually the neat solution is probably to treat frames as a ring, so 
that C-x 5 o would go back to the previous frame. Is there any reason 
why frames were not conceived as a ring, but ``rigidly''?


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