[OS X Emacs] Re: one-buffer-one-frame-mode strangeness with Spaces

[Ted Middleton]

Odd - I still don't seem to be getting digests or emails from this
list - and there's nothing in my gmail spam box? Oh well - I'll have
to keep replying to messages in the archive


>> The other problem is that when I close an aquamacs frame the space switches automatically to another space where there is an open aquamacs frame.

>This is indeed independent of one-buffer-one-frame-mode.  (In fact, Emacs Lisp-level modes do not know anything about spaces.)

>I haven't seen it as a problem, but changing this behavior shouldn't be too difficult provided it is indeed non-standard on OS X.

I'm guessing what's happening here is when emacs/aquamacs creates a
new NSWindow/frame, it's keeping track of which aquamacs
NSWindow/frame was most recently the key window, and then
re-designates that the key window by calling NSWindow -makeKeyWindow
or -makeKeyAndFrontOrder - I suspect that this is what triggers Spaces
to switch to a different Space.

Going back to my example, in Space 4 aquamacs has a NSWindow with the
somefile.txt buffer, and being the only NSWindow it's designated as
the key NSWindow. We switch to Space 7 and type 'aquamacs
otherfile.txt' and that tells aquamacs to open a new NSWindow/frame
with a buffer for otherfile.txt. If it all stopped there I think we
would be just fine, but I suspect that, for some reason, aquamacs is
then calling -makeKeyWindow: or -makeKeyAndOrderFront: on the first
NSWindow (the one in Space 4 with the somefile.txt buffer). I believe
(I'll test this later today myself) that this would trigger Spaces to
switch back to Space 4.