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

[Ted Middleton]

Incidentally, for anyone else who wants to fix this problem locally,
what I've done here is really an awful and kind of blind hack. Someone
who actually knows what he or she is doing needs to look at this code
more carefully than I have. In the meantime, I'll keep looking for the
code that transfers focus to other NSWindows/frames when an
NSWindow/frame is dismissed.


On Tue, Oct 26, 2010 at 12:14 PM, Ted Middleton <middleton.ted at gmail.com> wrote:
> 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))
>                ret))
>
> 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.
>>
>