[This site will look better in browsers that support web standards, but should be legible in all.]

Tuesday, 11/04/03

I started to take Cocoa seriously when Project Builder introduced the ability to use external editors. I've been writing perl in BBEdit for years, and finally I could use the same lovely editor for Objective-C. You don't mess with a man's editor, after all, and Project Builder's editor is distinctly unlovable.

Unfortunately, PB supported external editors passive-aggressively. Single-clicking a file in PB displayed its contents (required to visually trace a path of execution), but PB's syntax-aware symbol checking went away. This meant the ability to command-click the text "NSRun" and bring up a popup menu including "NSRunCriticalAlertPanel", useful both for remembering long symbol names and for quickly jumping to the right point in an arbitrary header file, effectively didn't exist unless the user wanted to dig into the prefs and shut off external editing.

Symbol awareness would have to have been rejiggered slightly to work in an external editor, but the path of least resistance could have meant refraining from inserting the selected symbol into the text, but still displaying its name and providing a shortcut to the relevant header file. Instead, they yanked the feature. That's sloppy.

Rather than fix this apparent oversight, Xcode makes the situation much worse. I can't even view a source file in Xcode when an external editor is in use. That's beyond sloppy, and into the realm of the punitive. It suggests that external editors were a check-off item for the Project Builder team, and once the feature was hacked together the subject was closed.

Xcode is an IDE. It's supposed to maintain file organization, support building and debugging, and make sure the trains run on time. There's no reason it has to micromanage the editing process, and no reason it should, because it's not so good at it, offering lackadaisical find-and-replace, botched scriptability, no Glossary, and none of the almost pathological extensibility that BBEdit has honed over its last three major revisions. I haven't been using Xcode long enough to know if it crashes less than PB did, but PB's instability was sufficient reason by itself not to trust it with maintaining open files.

Xcode's IDE features (smart groups, clever presentation of errors and warnings, the new symbol browser, zero-link, predictive compilation, and Rendezvous-savvy builds) all range from impressive to terrific, but its editor is still a hick town compared to BBEdit's thriving metropolis. I dearly wish Xcode would play to its strengths, and cut its losses.

Update:: My distaste with Xcode led me to write the above before I fully appreciated the depths of its hostility to external editors: as Michael Tsai points out, not only will Xcode-with-BBEdit refuse to display the contents of a file, it won't even show context during a debugging session. This is akin to, say, asking a mechanic why your car makes a rattling noise but refusing to let him turn on the engine, or look under the hood.

My temporary workaround:

Xcode contextual menu snap

I turned off external editing, then reassigned .m and .h files to BBEdit in the Finder. I can thusly open an Xcode file in BBEdit taking only about three times as long as doubleclicking. This is easier, I think, than constantly dragging Xcode file icons to BBEdit's icon in my process dock.

I am sure I will get at least half a dozen emails from people suggesting that a multiple-button mouse/trackpad would make this workaround more palatable. They are all correct, notwithstanding that the problem wouldn't exist if Xcode, in this critical respect, didn't try so hard to suck so much. I'm going to get up from a long coding session and find myself covered in hickeys. 04:09PM «

Bits pushed by Movable Type