GNU bug report logs - #3303
delete-frame raises old (invisible) frame

Previous Next

Full log

View this message in rfc822 format

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: David Reitter <david.reitter <at> gmail.com>, 3303 <at> debbugs.gnu.org
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,
        Adrian Robert <adrian.b.robert <at> gmail.com>
Subject: bug#3303: delete-frame raises old (invisible) frame
Date: Tue, 19 May 2009 17:20:20 +0900

>>>>> On Mon, 18 May 2009 22:56:32 -0400, David Reitter <david.reitter <at> gmail.com> said:

>> I still don't understand the above code, for the reason already
>> explained: you use `selected-frame' in a way that seems to imply
>> that you expect make-frame to change the selected-frame, where its
>> docstring says explicitly that it doesn't.

> Ah, now I see why you don't understand.

> The doc string says that the system may select it, and that's
> exactly what happens here on Cocoa/OSX.

That's due to the following NS-specific code in term/ns-win.el:

  ;; frame will be focused anyway, so select it
  ;; (if this is not done, modeline is dimmed until first interaction)
  (add-hook 'after-make-frame-functions 'select-frame)

I would read this comment as "this is a workaround".  TRT is to
investigate why the modeline is dimmed until the first interaction and
fix it, of course.  Otherwise, the NS port will face hard-to-find
incompatibilities in various elisp packages.

The docstring says "The previously selected frame remains selected.
However, the window system may select the new frame for its own
reasons, for instance ...".  In (non-NS) click-to-focus environments,
the selection of the new frame does not happen immediately but does
when the Lisp interpreter goes back to the command loop and reads
events (cf. docstring of select-frame).

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.