The Mac IDE I want
I’m not going to attempt to justify all of this, because every developer who’s been around the block more than a couple of times has utterly different ideas about this. What I do know is that, right now, this doesn’t exist and I want it to.
Basic layout. A window per project, similar at a superficial level to Coda. File browser in the sidebar (rooted on the project path), editor in the main content area of the window. Tabs for open files, as per Coda, TextMate, etc., but in contrast to BBEdit/TextWrangler/Xcode. This is a matter of huge contention (i.e., make or break) for some developers, though; perhaps a pref would be in order? It needs to look like a Mac app, though, and be fast and not, in itself, a huge memory hog. Sorry, Eclipse, NetBeans, etc.
The file browser needs to be fast, and never ever block the UI. Xcode and TextMate both suffer here: last I tried either of them, they were unusable on large trees over NFS or AFP (indeed, they’re pretty sluggish locally if your trees are big enough).
The file browser also needs to do pattern filtering and, most importantly, support version control plug-ins. Not just a smattering of built-in VCS support, but hand it off to a plug-in. Let the VCS experts deal with the version control.
Editor plug-ins. Don’t give me any of this “oh, you get a text editor and a CSS editor and a web browser” malarkey. Delegate it all. The plug-in deals with the content area, and its Info.plist describes the file types it supports, just like an application’s does. For a given file, I can right-click and switch between the various different plug-ins that I have installed and support the current file type, and I can stick my favourites on the toolbar.
This means that, for example, if Bare Bones wanted to sell a plug-in-ified version of BBEdit’s text editor engine, I could drop that in and use that in place of whatever engine this IDE shipped with. I can pick the one I prefer. I don’t just mean text editors, either: what if—say—Acorn were packaged up as an image editing plug-in, or somebody wrote a visual editor for XML files? All of this could be dropped in without requiring a major update to the IDE—and, most importantly, without requiring the IDE author to get involved in the slightest.
- Non-editor plugins. Although I have terminal windows open all the time, I use Coda’s “Terminal” mode endlessly. Having a terminal which is both visually and conceptually linked to a project is very useful indeed, and if I have several things going on, switching between a terminal and an editor tab is something I can do far faster than switching between an editor and Terminal.app and cycling windows in both cases. Lots of scope for other things, here: database browsers, documentation viewers, even VNC clients.
You know what? That’s actually it, in a nutshell. I don’t want an IDE which ships with all the bells and whistles in the world. But I do want one which makes it easy for the various people out there who are good at creating the various bells and whistles to slot them right into place after the fact. Ship it UI-complete with a well-defined plug-in architecture and a basic text editor and see what happens.
There are, of course, other things which you’d want: (user) scriptability, for example, and getting the plug-in architecture right wouldn’t be an easy task. Do you support SFTP browsing from the file browser, for example? How do you present that? Would you just provide space for “Local” and “Remote” and let plug-ins fill in the gaps (with a default implementation of “Local” that was good enough for most folk)?
I do wonder if this approach would be easier, and potentially more fruitful, than attempting to create the perfect all-in-one Mac IDE (and significantly more Mac-native than attempting to create a cross-platform all-in-one-and-then-some IDE).
