Cocoa development in Emacs - Part 3
So, why did I go to all of the trouble to figure this stuff out?
I’m probably not your typical Mac developer, living inside of CodeWarrior most of the time. Way back when (in 1985 or so), I started programming the Mac using TML Pascal, which was pretty much just a compiler tool. (I wasn’t rich enough to afford a Lisa to use the development environment, and was too much of a wuss to learn 68K machine language to use the Mac native assembler.) The work cycle was editing my code in “Edit” (the programmer’s editor) and then telling the editor to run the compiler. The editor was lean and mean. No fancy formatting, no second-guessing my intentions. I found the toy Macintosh Pascal environment (and later Lightspeed Pascal) editors to be infuriating for that reason. Make one typo which causes a syntax error and your code would be drawn outlined (e.g. unreadable, frequently shooting the line halfway across the screen, since outlined type is nearly twice as wide as regular type). It would also force a particular indentation style, with no deviation (even if you had good reasons to). So I stuck with Edit and TML Pascal. Lightspeed C came out shortly thereafter with a very simple stay-out-of-your-way editor plus a disturbingly fast compiler. I was in nerdvana.
Then along came MPW, the Macintosh Programmer’s Workshop, which I started using in 1989 or so. I loved it. I never really comprehended the command line stuff at the time but I managed to have a nice worksheet of commands I could execute, and the editor was pretty much invisible to the work I was doing.
My first job out of college was at a Unix shop where I found and fell in love with Emacs. After I got used to the pretty bizarre (to my mind) command keys, I just moved in with all my stuff. I ran all my shells in one Emacs process. I read my email there. I edited source code, compiled programs, and ran the debugger from there. My coworkers gave me a hard time because we were developing a programmer’s graphical toolkit but I did most of my work in a single Emacs window the size of my screen (split down the middle with C-x 3 so I could see my header file and C file at the same time side-by-side in 80-column frames). And to top it off, the automatic indentation features of Emacs actually worked well. It fit my coding style like a glove (with one exception involving the case labels in a switch statement, but I’m too lazy to find the final tweaks to address that).
After that job, I was at AOL working on publishing tools for the 3.0 Mac client (as well as doing some small parts of the client itself) in C++ and PowerPlant. There I used Preditor as my editor (a really cool, if a bit unstable, editor. When you’re trapped in mouse-land, the grabbing-hand scrolling was a godsend) and Metrowerks Code Warrior as a compilation engine driven by the editor. (And to prove how off-kilter I was, I used and loved Jasik’s The Debugger rather than the CW debugger.) When the publisher team got sent away to California, I did Web server programming (Emacs + C) and later Web site programming (Emacs + Oracle + Tcl) on various flavors of Unix.
And now comes Mac OS X, my ultimate fantasy. Wicked cool NeXT technology (even though the bastards wouldn’t sell me a machine back in 1989 ... grrrrr) in the form of the Cocoa libraries, Unix underware, plus the delicious Mac OS fluffy goodness I’ve come to expect from Apple. Time to start programming on this Dream Team of technological magic.
There was just one problem : Project Builder. I love Emacs. Tons of power
packed into an unobtrusive editor. Project Builder, which I’m sure
is great for those who like IDEs, just grated on my nerves from Day One.
It supports Emacs key bindings so my fingers felt at home, at least until I
discovered that there were some fundamental differences – like
C-v scrolling the window but not moving the cursor, or
frequently used commands (like
C-x C-s to save a file)
that weren’t bound.
Add to that the panels that slide around on their own power whenever
you compile or run a program. I found myself doing a lot of panel
position maintenance (and getting frustrated waiting for the panels to
finish their moving. Yes it happens quickly, but it’s still a non-zero
amount of time consumed for eye candy I’m not interested in or
impressed by). I know that
Command-Option-M will close various panels, but I
occasionally didn’t hold down the Shift or Option keys hard enough and the
(very annoying – I’m still easily annoyed)
combination dutifully sent my window to the Dock. So much for my
train of thought.
The indentation features of Project Builder also didn’t work nearly
as well as they did in Preditor (or the ancient Edit as well). Sometimes
you’d backspace over a single space and the editor would decide to
remove a tab or two. It also only supported indent / outdent by a tab stop
Command-[) but not by a space (e.g.
Shift-Command-[). I’m also very
particular about my code presentation, and not having that kind of control
(in lieu of the indentation features of Emacs) was maddening.
The final straw was not being smart enough to figure out how to remove the ’breakpoint’ bar from all the text editor windows. I never use it yet I was always clicking in it, leaving stray breakpoints around (which annoy me, so I just have to remove them), so a stray click led to dumping my train of thought plus a click-drag to remove the breakpoint (since just clicking on it again wouldn’t remove it, instead drawing it grayed out). I know, I know, “Wah, poor baby, bothered by the widdle biddy breakpoint arrows.” Go stuff yourself. I don’t want my development environment to annoy me.
After working through Aaron Hillegass’ book completely in Project Builder, hoping either to drink the Kool-Aid and learn to love Project Builder’s editing environment, or perhaps to come across a project that required some spiffy Project Builder feature, I decided to figure out how to do all of my editing, compiling, and debugging entirely inside of Emacs like in the Good Old Days. The other stuff that Project Builder does well, like managing and building projects, and tweaking build parameters, I’ll let Project Builder handle. Also since I’m planning on sharing a bunch of source code with the world, I figured I better supply Project Builder projects if I expect folks to actually use them.Back to Part 1 Back to Part 2