GNU bug report logs -
#3303
delete-frame raises old (invisible) frame
Previous Next
Full log
Message #40 received at 3303 <at> emacsbugs.donarmstrong.com (full text, mbox):
On Sun, May 17, 2009 at 10:43 PM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>>> Still, the
>>>
>>> #ifdef NS_IMPL_COCOA
>>> /* term gets no other notification of this */
>>> if (for_deletion)
>>> Fraise_frame(Qnil);
>>> #endif
>>>
>>> in frame.c looks plain wrong and should probably just be deleted:
>>> frame-selection is never intended to raise (or lower) any frame.
>>> If this `raise' is really necessary, then it needs a much more extensive
>>> comment justifying its presence.
>>> Adrian, could you remove this code, or justify clearly why it's here?
>
>> I think it is there because we need to raise another (visible) frame when
>> a frame is deleted. This is standard behavior (and sensible).
>
> This is a behavior which depends on the window-management policy, so
> it's the responsibility of the window-manager (which may even decide
> that the focus should return to some other application, which would make
> a lot of sense if the frame was created via $EDITOR=emacsclient).
Shouldn't then frames created via emacsclient be a special case? That
would of course make more sense if the frame was deleted together with
the buffer opened through emacsclient...
For other frames both leaving it to the window manager and staying in
Emacs makes sense to me. Maybe a user option (if it is possible to
stay in Emacs at all)?
> So, I'd still want to know what undesirable behavior would happen under
> NS if we don't call Fraise_frame here (and also, why it needs to be
> called here rather than elsewhere).
>
>
> Stefan
>
>
>
>
>
This bug report was last modified 13 years and 288 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.