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

Ted Middleton middleton.ted at gmail.com
Tue Oct 26 15:14:16 EDT 2010

Well, I've had a look at it, and at least I know where it's going
wrong. In Resources/lisp/aquamacs/one-buffer-one-frame.el at line 578
we have:

		(unless (eq display-buffer-reuse-frames 'select)
		  ;; we can't use select-frame-set-input-focus because
		  ;; that would raise the (main) frame over the newly
		  ;; opened one, and we don't want that.
		  (select-frame sframe)
		  (cond ((memq window-system '(x mac ns))
			 (x-focus-frame sframe))
			((eq window-system 'w32)
			 (w32-focus-frame sframe)))
		  (select-window swin))

If I turn the "(x-focus-frame sframe)" into "()", this problem goes
away and aquamacs doesn't try to return me to another NSWindow. I
don't know what knock-ons this introduces (probably lots?) but I've
made this change locally and it's working quite nicely for me.

The next problem is that when I dismiss the NSWindow, aquamacs tries
to change the focus to another NSWindow, again, in another Space. I'll
try to hunt down where this is happening.

On Tue, Oct 26, 2010 at 9:41 AM, Ted Middleton <middleton.ted at gmail.com> wrote:
> 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.

More information about the MacOSX-Emacs mailing list