"Split views: Yes, I actually had this on the alpha milestone, I’m not overly excited about this feature myself, but I know it’s a very common request, so eventually it should find its way into the application."
It's not necessarily about having two files open at once. More often than not I want the same file open in two windows so I can reference one part while I work on another. This can be done in TextMate but not easily. TextMate also doesn't quite make it easy to open different files in the same project in different windows: It's something like Go to File (command-t), Reveal in Project (command-control-r), right-click on the file and select Open in New Window (no keyboard shortcut). You should be able to do this entirely from the keyboard but you can't within the confines of TextMate.
I also happen to work on a project with 24k+ files, which even with an SSD TextMate does not do well with. I have a script to generate a tmproj file[1] that contains the files I want to make it manageable.
The problem is if you open a new window with "Open "filename.ext" in a New Window" and then try to do something like Cmd-T or Find in Project in the 2nd window it doesn't work. So you'd have to open the project again, jump to the file you want, and hide the drawer.
New windows should be a part of the same project they were opened from.
The OS isn't better at it if there is none or limited ability to manipulate the windows in a keyboard driven way.
I use and love the 3rd party tool SizeUp, but SublimeText2's integrated pane management (including moving tabs between them) is far better than plain windows.
On linux, I've been using tiled window managers exclusively for about three years now and the lack of good tiling features is almost painful when I use windows (though the win7 tiling features certainly were a welcome addition). I personally hate having to reach for the mouse if I'm typing, so tiled window managers are a perfect fit for me.
I've been using musca[1] because out of the bocks, it works exactly how I wanted a window manager to work and at the time it was well maintained. Though it doesn't seem to be maintained anymore, but I have not had any problems with it (plus the source is available anyway, so I could always attempt to extend it myself should I ever need to).
In Vim there are many benefits from having multiple buffers open within the same Vim instance. Buffers share session data of the Vim instance they're in. This has a lot of different benefits, including automatically sharing whatever options or settings have been set (many dynamically or temporarily set), sharing of Vim registers, macros, and command history, all of which are heavily used when editing (if OS handled they would generally share a single clipboard register), Vim-controlled navigation between buffers and windows, Vim-controlled scripting between multiple buffers, Vim-controlled searches of multiple buffers, and more.
Because there are so many benefits of having multiple buffers/files open within the same Vim instance it makes sense to have multiple buffers viewable at once, not to have only one viewable at a time. You lose a lot of editing power if buffers are not open in same Vim instance; it doesn't make sense to open a new file separately in different Vim instance. Moreover, many times split windows are useful to show two different views of the _same_ buffer at once.
Because then I've gotta deal with two windows. Cmd+~ : One's now in the background, the other isn't. Switch apps, one comes back, the other doesn't. Switch monitors, the sizing's off. Try to do anything other than 50/50 split, have to adjust manually. Try to use TM's project browser (seriously), doesn't work. Try to swap that second file for a different one, have to close the window, open a new window & reposition. It's generally a much clunkier workflow.
Granted, I only know that from using VIM (and occasionally SublimeText), but it's been one of my "Dear GOD Give Me This in TM" requests for a while. I've got SizeUp and love it - truly one of my must-have apps - but to me it's a hack, not a solution.
The wording of "I'm not excited about it but I'll do it" has me worried. Typically those kind of things end up poorly executed/implemented.
In terms of split views, its not a big issue for me, but to publicly state that is your approach has me unsure about other parts of TM2 and his practices. I don't look at it thinking "yay!"
(I'm not a desktop app developer, so maybe I'm way off base here.)
There's the obvious observer problem where you have two views of the same buffer and changing the text in one automatically updates the other. Isn't that harder to tack on later than to design into the app from the beginning?
Depending on how well you can map your code to the built-in Cocoa text-editing classes, this could be as easy as adding two NSLayoutManagers (each directing one NSTextContainer and NSTextView) beneath a single NSTextStorage instance. Apple even uses this configuration for one of their examples:
http://developer.apple.com/library/mac/#documentation/cocoa/...
The built-in notifications and delegate-relationships handle everything else (updates & synchronization) automatically. This is actually NeXTSTEP-level stuff that's been around for decades.
How do you code looking at two files at one time? What's the point?
I've been programming for nearly thirty years now. For the bulk of that time, I had an editor which allowed me to do split screens, and I used it maybe once a year. I switched to TextMate in 2008, and have never once missed having a split screen.
different strokes for different folks. i look at one buffer at a time, and switch between them. have only rarely made use of split views. helps me mentally with encapsulation/separation.
There's no projects in TM, if you open a folder it opens up the folder in the project drawer. From there (or from Finder) you can open up as many editing windows as you want.
"Split views: Yes, I actually had this on the alpha milestone, I’m not overly excited about this feature myself, but I know it’s a very common request, so eventually it should find its way into the application."