BBEdit 8 is now shipping, and there are copious release notes, far too many to discuss. If I don’t mention one of the new features, it doesn’t mean that I dislike it (or that like it), just that I didn’t have anything in particular to say about it.
BBEdit’s interface, long derided as behind the times, has been re-done using Nib files, and it uses sheets and drawers—where they make sense—as well as the font panel. The spelling checker is now non-modal. Although under the hood the changes were likely major, on the surface the differences are minor. Overall, BBEdit 8 still feels like BBEdit, only better.
There is one major interface change, though: BBEdit can now open more than one document in the same window. This is similar to how Xcode and tabbed browsers work, and I’ve never really been a fan of this kind of interface. I think that’s because I’ve never seen it done right. BBEdit 8 gets it almost right, though, and as a result this feature has been growing on me. I often have many different documents open in BBEdit, from different projects, and grouping them into a few windows makes them easier to manage. There’s less overhead than in using BBEdit’s File Groups, and as a result I am using the Documents drawer more often. The main problem is that the resulting window arrangements are too ephemeral. They should be saveable, along with the palette positions, in Workspaces, or else someone should write an AppleScript that saves and restores window states. Also, I can’t tab into the Documents drawer; I have to click in it, which almost defeats the purpose of type-selecting.
Codeless Language Modules are here at last. There is already a module for Apache Configuration Files. BBEdit still uses its code-based language modules for most of the built-in languages, and so it kind of offers the best of both worlds: speed and accuracy for the common and difficult-to-parse languages, and easy extensibility for languages with standard tokenization. However, we’re not quite there yet, because the codeless language modules are a little under-powered. They don’t support regular expressions so, for example, the Apache module can’t color the pseudo HTML tags. Only one set of keywords is supported per language. And there is no way to take advantage of BBEdit’s existing language modules, e.g. to embed your new language (or one of the built-ins) into HTML. Language modules are still limited to coloring and the function pop-up; there is no language-sensitive indentation or navigation assistance, as in Emacs.
- Language guessing is much better. CVS integration is improved, with support for Perforce added, and Subversion on the way.
- Preferences are now stored using the defaults system.
- It’s nice that the HTML checker can ignore parts of documents and also check partial documents.
- Multi-file Find and Replace is much improved, with more flexible folder selection and background processing. Whenever I hear about a new text editor that’s “better than BBEdit,” the first thing I do is open its Find and Replace window. Then I run back to BBEdit.
- Text Factories are kind of neat, but BBEdit was already scriptable.
- Reopen Using Encoding, Compare Front Documents, and the new bbdiff tool obsolete similar home-grown scripts that I’d been using.
- State is now stored in a property list, keyed by path, rather than in resource forks. As a result, when I move my files around (or just let them sit around for a few weeks), BBEdit forgets minor state, like the window position and insertion point, and major state, like the encoding and tab settings.
- The Convert to ASCII command is gone. Straighten Quotes is a poor substitute.
- If only Apple would let third-party developers display Xcode compilation errors and access CodeSense.