![[PDF]](/shelf/images/pdf-icon.png){kind=icon}
All applications are software; but not all software is an application. The key difference is the primacy of the user interface in application development. To paraphrase Edward Tufte, the user interface is the application—whereas most non-application software doesn’t even have a user interface.
From the perspective of a programmer, all software is just source code. In a broad sense, the source code for a ui-less background process such as the Apache web server very much resembles the source code for a gui application. Developers’ relationship with the software they produce is abstract, conceptual. When an artist wants to produce a circle, he draws a circle. When a programmer wants to produce a circle, he writes a few lines of source code. It is the ability to grasp these abstractions that separates programmers from non-programmers.
From the perspective of users, however, the importance of the user interface is profound. For users, the application is what they can see, click, and interact with. A user’s relationship with an application is perceptual, sensual.
The raw capabilities of a particular application are, for most users, irrelevant; it’s the usability that matters. Features which aren’t presented via an intuitive, discoverable, usable interface might as well not even exist.
For something as inherently nerdy as a text editor, BBEdit is phenomenally popular. But its appeal is not universal: in addition to those who simply have no need for a serious text editor, or who simply prefer other editors, there are vocal contingents of BBEdit non-believers who profess outright bewilderment at BBEdit’s decade-long dominance of the Mac text editor market.
There are two vectors for such bewilderment, both of which belie a genuine understanding of what it is about BBEdit’s “interface” that makes it so beloved:
This is not to say that aesthetics are unimportant. To find something aesthetically pleasing is deeply satisfying in a left-brained way. But aesthetic appeal is but one aspect of user interface design, not the whole of it—and for a serious tool, not the most important aspect. Compare and contrast to, say, choosing an office chair. It’s certainly nice to have a chair that looks good; but if you’re going to be sitting in it 8 or more hours every day, ergonomics are much more important than aesthetics.
I won’t dispute that BBEdit’s interface is relatively unadorned; but so while it’s not pretty, it isn’t trying to be. Handsome is perhaps more apt. The layout of windows, dialogs, and menus is meticulous and thoughtful. The point is not to impress you; the point is to enable to you get work done.
This view is generally expressed only by those who are extremely technically nerdy—i.e. the sort of guys who honestly see Mac OS X as Unix with a Mac gui, rather than as an updated version of the Mac OS with Unix-like underpinnings. Their question to BBEdit advocates, invariably, goes something like: “What does BBEdit do that [my favorite open source editor] doesn’t do?”, where the variable is usually Emacs or vi/vim—or occasionally jEdit.
The problem is that this is not the right question. Emacs, Vim, and their various derivatives are very fine editors, and inarguably offer many powerful features. They are also difficult to learn, cryptic to the uninitiated, and their human interfaces (such as they are) are unlike anything a Mac user would consider normal. Some would have you believe that such is the price of power—that easy-to-use and powerful are mutually exclusive.
The appeal of BBEdit is in its balance of powerful text-editing features and an elegant, intuitive, and unabashedly Macintosh-style interface—and where by “interface” I don’t mean in the sense of superficial cosmetic appeal, but in the deeper, interactive sense.
It’s also worth pointing out here that “easy-to-use” is probably not the right adjective. Once you have learned to use any software package, no matter how cryptic its user interface may be, it can be very “easy” to use. Hence it’s true that one might find Vim easy to use if one takes the time to learn it and grow acclimated to its keystroke-driven interface. But that’s a big “if”. The Macintosh’s main appeal is not that it is easy-to-use, but rather that it is easy-to-learn. The difference is significant, but often overlooked.
Furthermore, it’s also worth pointing out that, ironically, the most compelling case for adopting Emacs or Vim as one’s primary editor is not their feature sets, but their interfaces. Specifically, the fact that they run everywhere in almost exactly the same way. Any system with a Unix-like shell can run these editors, and as of 2004, every significant desktop operating system either ships with a Unix-like shell or has one available as a free download. Thus, if you master Emacs or Vim, you can rightly feel quite confident that you’ll be able to use it on every computer you use for the rest of your life.
If by circumstance or choice you use both a Mac and one or more non-Macs, it’s an appealing thought to be able to use the same editor on every system—using the same keystrokes, shortcuts, and customizations.
Text editing habits run deep. Mac users forced to switch to Windows regularly plead with Bare Bones to port BBEdit to Windows. Windows users who switch to the Mac regularly badger Bare Bones to make BBEdit more like their favorite editor from Windows (e.g. UltraEdit or TextPad). And, I’m guessing, after giving up on a BBEdit port to Windows, former BBEdit users start badgering for the BBEdit-ification of UltraEdit and TextPad.
Emacs and Vim users, on the other hand, just copy their configuration files from one machine to another—be it Windows, Linux, or Mac—and they’re right at home.
Which brings us to BBEdit 8.0, the latest version of Bare Bones Software’s flagship text editor, released with much fanfare two weeks ago. Before we proceed, let’s just get it out of the way and link to my standard I-used-to-work-for-Bare-Bones-Software disclosure.
The first thing you’ll notice is that BBEdit 8 sports a new application icon. The stately capital B set in bold Palatino—a hallmark of BBEdit’s iconography since its public debut 12 years ago—has been replaced by something, well, a bit jauntier:
With the release of BBEdit 8.0, has come the most inexplicable new feature. The application icon has been updated with the most grotesque typography, looking like a Comic Sans derivative.(Hicks whipped up a replacement icon, which, whatever you think of the new BBEdit 8 icon, is far worse—not because it’s unappealing, but because it’s un-BBEdit-y.)
But what the hell is up with the new BBEdit 8.0 icon? That has to be the worst looking “B” I’ve seen in some time. It almost looks like a “B” from Comic Sans! And we all know how catastrophic that is.
The most essential new aspect of BBEdit 8 isn’t what it looks like, or even what it does, but what it doesn’t do—which is run on Mac OS 9. In fact, not only does BBEdit 8 only run on Mac OS X, it requires 10.3.5, due to several bugs in earlier versions of Panther. (Having beta-tested BBEdit 8 under pre-10.3.5 builds of Panther, I can attest to this.)
This isn’t just an idle milestone—BBEdit 8’s Mac OS X-only nature informs nearly all of its major new features.
This is not to say the last few versions of BBEdit didn’t take advantage of Mac OS X-only features. E.g., shell worksheets and the built-in Web Kit html preview, which for obvious reasons were only available when running BBEdit on Mac OS X.
Now that it only runs on Mac OS X, however, BBEdit 8 can take advantage of OS X-only features throughout the entire application, including UI widgets only available on OS X. Most of the additions and changes to BBEdit 8’s user interface are tied to OS X-only controls and conventions.
I see no need to provide a comprehensive overview of every new feature; Bare Bones’ web site does a good job of that. And if that’s not enough information for you, the full change notes are available: over 300 bullet items spanning 27 printed pages. Needless to say, by any measure, this is a significant update.
The most profound addition is the new multiple-document interface. Analogous to tabbed browsing with Safari, you can now open multiple documents within a single BBEdit text window. A window’s open documents are displayed in a drawer on the right side of the window.
Thus, the multi-document interface is much more like OmniWeb’s “tabbed” browsing than Safari’s. And like OmniWeb, BBEdit 8 allows you to drag documents from one window to another. Clicking an icon in the status bar opens and closes the Documents drawer. (A nice touch: if the Documents drawer in the front window is closed, it will open automatically if you hover a dragged document on top of the drawer-toggling icon in the status bar.)
It’s a radical departure from previous versions, where every text window represented one document, and every open document was in its own window. But it doesn’t feel radical. It just works, exactly how you’d expect it to. You can ignore it, you can use it all the time, or, you can use it when you want. I’ve been using the feature since it debuted during beta testing, and while I tend to use the traditional one-document scheme most of the time (if for no other reason than a decade of habit), I’ve found the multi-document interface convenient for grouping related files together.
If you don’t want to give up the screen real estate for the documents drawer, you can keep it closed and switch between open documents in the front window using the also-new Navigation Bar, which looks and works very much like the Navigation Bar in Xcode.
BBEdit 8 now uses atsui for text rendering. In all prior versions of BBEdit, the rendering engine was implemented using QuickDraw, a set of apis dating back to the original Mac. This is an enormous under-the-hood change, text rendering being a core task of a text editor.
If you only use roman character sets, you likely won’t notice that anything has changed—text editing and rendering looks and feels identical to that of BBEdit 7. Where the new atsui-powered engine shines is in the rendering of Unicode text. BBEdit now supports multiple languages—e.g. Chinese, Japanese, and English—all within the same document. If you don’t need advanced Unicode support, BBEdit’s new atsui-powered rendering engine works just as well as the old QuickDraw engine. If you do, you can now use BBEdit for tasks it previously couldn’t handle. For a small subset of BBEdit users, this is one of the biggest improvements in the history of the app.
BBEdit’s handling of text file encoding formats has also improved greatly. A new Reopen Using Encoding sub-menu in the File menu allows you to manually specify the text encoding for a given file. Thus, if you open a file saved using Windows Latin 1 encoding, but BBEdit displays it as Mac Roman, you can easily reopen the file with the proper encoding. With BBEdit 7, you needed to close the file, then reopen it using the Open dialog box, specifying the text encoding using a pop-up menu in the dialog. There were other ways to do this (Marc Liyanage’s character set conversion Perl filters and the Midex BBEdit plug-in, for example), but nothing as easy or graceful as the new Reopen Using Encoding menu.
BBEdit’s multi-file searching allows BBEdit to act as a production tool for batch processing many files at once. Sure, it’s nothing a short Perl or Python script couldn’t do—but if you think everyone can or should learn to program, you’re missing the point.
But there’s only so much a single search/replace can do. It’s great if you need to something simple, like changing the copyright date across a few thousand html files. But if you need to string together multiple replacements, it’s no longer a one-step process.
Enter “Text Factories”. A Text Factory is a new type of document that contains a list of one or more actions. You can easily add or remove actions similar to the way you add/remove search criteria in the Finder’s Find window: via ‘+’ and ‘-’ buttons next to each action. Text Factories seems conceptually similar to the Automator feature coming in Tiger.
You can execute a Text Factory against a single document window, but the real power comes when batch processing files. If you regularly perform the same repetitive actions against multiple files, a Text Factory might be able to automate the entire process, without scripting.
And even if you’re comfortable with scripting—whether with AppleScript or a shell language—Text Factories still might prove useful for batch processing. If you write your script to serve as a Text Factory action, the script only needs to be concerned with processing the text of a single file at a time, saving you from writing code to recurse folders and loop through, open, and save files—which I consider a minor pain in the ass even in Perl.
Multi-file Text Factory processing can also take advantage of the same file filtering mechanism used in BBEdit’s multi-file searching, making it easy to limit Factory processing based on attributes such as file names, modification dates, and labels.
One obvious improvement for the future would be to allow Text Factories to be saved as “droplets”—small applications that you can drag files and folders to in the Finder. Adobe Photoshop and ImageReady allow their actions to be saved as droplets, and it’s a convenient way to invoke them when processing multiple files at once.
Speaking of multi-file searching, BBEdit’s mighty Find dialog has received a makeover. Turning on multi-file searching now opens a drawer on the left side of the dialog. The drawer contains a list of search targets: all open documents, recently-searched folders, and every html Web Site configured in BBEdit’s preferences. It’s better-organized and more convenient than the pop-up menus it replaces.
Plus, multi-file searches now run in their own thread, which means that searches can run in the background while you continue to work in BBEdit. Even though most searches I run take only a few seconds to run, it’s a nice improvement when I do run a lengthy search.
I mentioned this feature previously, when I released my Apache Configuration language module. Out of all the new features in 8, this is probably the one that most deserves a response of “It’s about time.” Prior to version 8, language modules for BBEdit needed to be compiled plug-ins written in c/c++. The advantage to this is that BBEdit’s compiled language modules are both powerful and very fast. The disadvantage is that most people aren’t willing or able to create them on their own.
Most text editors follow the opposite approach, and only support languages modules in a plain text format. Now that BBEdit supports both, it should provide a best-of-both-worlds experience.
However, BBEdit 8.0’s codeless language module mechanism currently has a few shortcomings. It’s more than a little biased toward programming languages, with good support for things like functions, string delimiters, and keywords. What it’s not so good for are markup languages. (Like, say, Markdown.) The current clm mechanism has no concept of things such as tags, and it doesn’t allow for using regex patterns to match language constructs.
Nor does it allow for embedding one language within another, the way BBEdit’s built-in language module for html supports inline chunks of other languages, such as php, asp, and css.
Speaking of compiled plug-ins, BBEdit 8 now supports plug-ins compiled using Xcode (i.e. Mach-O binaries). Previously, BBEdit required plug-ins to be cfm binaries, which effectively meant they had to be compiled in CodeWarrior. This restriction pretty much eliminated hobbyist-level plug-in development, combined with the fact that many of the text-munging tasks tackled with plug-ins a decade ago are now much more easily written in Perl or Python. BBEdit 8 still supports old-style cfm plug-ins, with the sole restriction that it no longer supports plug-ins that aren’t Unicode aware.
Also, a bunch of plug-ins that used to ship with BBEdit are now built-in commands in the Text menu: Add/Remove Line Numbers, Prefix/Suffix Lines, Sort Lines, Process Duplicate Lines, and Process Lines Containing. This, combined with the fact that other third-party plug-ins have been obsoleted by other new features in 8.0, has left me with zero plug-ins (other than language modules). Examples of obsoleted plug-ins: BBTidy (html Tidy is now available via BBEdit’s Markup menu) and Midex (no longer necessary thanks to the aforementioned Reopen Using Encoding sub-menu). I had a plug-in I wrote years ago for myself but never released, Stupefy Quotes, which has been obsoleted by the new Straighten Quotes command in the Text menu.
I’m be interested to see whether support for Xcode spurs a surge in plug-in and compiled language module development. I’m guessing no for plug-ins—Unix Filters have eaten their lunch—but yes for compiled language modules.
By dropping Mac OS 9 support, BBEdit is now able to fully support os-x-style conventions for supporting files:
This scheme was quite clever, and worked exceedingly well in the old Mac OS world. The only thing essential is the actual text of the document, which was stored in the data fork. By stashing state info in the resource fork, you could preserve it by passing it from one resource-fork-savvy medium to another. Send it to someone on Windows or Unix, and the state data would be lost, but the actual text in the data fork would be unaffected.
In the new world of Mac OS X, however, storing state data in resource forks has significant downsides. For one thing, resource forks don’t survive the roundtrip through version control systems such as cvs or Subversion. It also causes problems with files are stored on file systems that don’t support multiple forks, such as WebDAV or ufs.
For those reasons and others, BBEdit 8 has switched to an entirely new system for storing document state. Instead of storing state data inside each file, you get a single preference file that contains the state info for every file you edit. It’s stored in a new file inside com.barebones.bbedit.PreferenceData: “Document State.plist”.
This solves all of the aforementioned problems with resource fork state info—you can commit a file into cvs, check out a new revision, and your state settings for that document will be preserved. If you work with multiple collaborators on the same set of files in a cvs repository, each of you can maintain your own state settings for each file.
This is not to say there aren’t downsides to the new system. The new centralized state database is fragile—it references individual files by, of all things, a hardcoded pathname. Thus if you rename or move a file, BBEdit loses track of its state. Move it back and the state settings come back.
This is clearly a trade-off. For anyone who works in a cross-platform environment or depends upon non-resource-fork-savvy tools, the new system clearly works better. However, for anyone for whom resource fork state storage did not pose a problem, the new system may not work as well, particularly for anyone accustomed to state persisting when you rename, move, or copy the file.
BBEdit 8 offers a much more os-x-like notification: a transparent status window and fades in and out.(similar the ones the system displays when you change the volume or display brightness).
