On Jul 14, 2:02 pm, David Alan Hjelle <[email protected]> wrote: > On Jul 14, 12:07 pm, björn <[email protected]> wrote: > > > > > > > 2009/7/14 David Alan Hjelle: > > > > I did notice, however, that there is a preference that probably > > > affects this, but I'm a bit unsure how it ought to be set for the > > > behavior I want. It's in General → Open Files from Applications: > > > > I have it set to "In the current window" "with a tab for each file." > > > as that is the behavior that I want within a single space. > > > > It appears that if I set it to "In a new window" "with a tab for each > > > file" that the double-click stays within the current Space as desired, > > > but, of course, subsequent double-clicks open up new windows. > > > > I *think* that most people would want the "in the current window" > > > options to only hold true while there is a current window in the > > > current space, but I can't claim to be an omniscient user. > > > > Does toggling that option allow you to reproduce the bug? > > > Ok, now I understand what's going on. Yes, with that option enabled > > it will switch Spaces for me as well. But as you probably realize > > this is by design -- since when "current window" is selected the file > > will open in the "current window" (duh) regardless of the Space the > > window is in. > > > It kind of sounds like it could maybe perhaps sort of make sense to > > not switch Spaces on this option, but I can think of reasons why you > > wouldn't want to either: E.g. you have Xcode on one space and your > > MacVim editor window on another Space and use MacVim as the "external > > editor" for Xcode with this option enabled. On the other hand, my > > first thought is that maybe you should not use this option to begin > > with? > > > Does anybody else who uses the "current window" feel like weighing in > > on the issue as to whether or not MacVim should ignore this option if > > there is no MacVim window on the current Space? > > > At any rate, this is all academic at this point in time since I don't > > know if it is even possible to check which Space a window is on. Does > > anybody else know of an API that lets you do this (a quick search > > didn't reveal anything, but I did not look that hard)? > > > Björn > > Björn, > > Yeah, I'm trying life with the other option for a while, to see which > is less annoying. :-) Ultimately, it's really a problem with Spaces > and its behavior. And I certainly realize that there could be other > workflows that the current behavior is exactly what is wanted. > > Of course, if others want the behavior changed (or yet another > preference added), I'd be thrilled. :-) > > I suppose this is really only an issue for apps that use tabs or > similar. Otherwise, a new window in the current space would always > work right. ;-) > > Thanks for your time! > > David Alan Hjelle
So I'm still doing a bit of research, but I found out something interesting: Terminal seems to have what I think is the correct behavior. In other words, if I have several Terminal windows open in several other spaces and not the space I'm currently on, then a ⌘-T (new tab) opens a brand new window in the current space rather than adding a tab to a existing window in a different space. I'm still trying to figure out Safari's behavior, as I suspect I once set a hidden preference or two to force new tabs to open in existing window: something like: > defaults write com.apple.Safari TargetedClicksCreateTabs -bool true Once I restart Safari, I'll experiment with that option to see if there is a standard behavior or if I should file a bug with Apple. Regardless, if there is interest, it appears that Terminal, at least, is able to determine which spaces its windows are currently in. David Alan Hjelle --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_mac" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
