Skip to Content
Skip to Table of Contents

← Previous Article Next Article →

ATPM 8.12
December 2002





Download ATPM 8.12

Choose a format:

Review: BBEdit 7.0.1

by Michael Tsai,


Developer: Bare Bones Software, Inc.

Price: $179; $119 (cross-upgrade from free BBEdit Lite); $49 (upgrade); $59 (upgrade after 2003-01-01)

Requirements: Mac OS 9.2.2 with CarbonLib 1.5 or Mac OS X 10.1.5

Recommended: Mac OS X 10.2.2

Trial: Fully-featured (30 days, watermarked printing, periodic nagging)


BBEdit is a powerful general-purpose text editor with a strong Macintosh heritage. Although it’s useful for a wide variety of tasks, many of the features are designed specifically for Web developers and programmers. ATPM has previously reviewed versions 4, 5, and 6. This review will focus mainly on what’s new in BBEdit 7.

Mac OS X

BBEdit has run natively on Mac OS X since version 6.1, and version 6.5 made it a better Mac OS X citizen by combining the OS 9 and OS X versions into a single file and adding such features as authenticated saves, a command-line “bbedit” tool, shell worksheets, and long filenames. BBEdit 7 continues this trend. The BBEdit application is now, an application package that contains separate executables optimized for OS 9 and OS X. The application package includes Apple Help and the 330-page PDF user manual (as of version 7, an HTML version of the manual is also available), making for easy drag installs of the application and documentation. BBEdit plug-ins can be installed with a simple drag and drop onto the application icon. You can now install the “bbedit” command-line tool from the preferences window, eliminating the need for the separate installer and its disk image. The BBEdit Support folder—which contains dictionaries, glossaries, plug-ins, language modules, scripts, etc.—is stored outside the application package. Each user can now have her own BBEdit Support folder in ~/Library/Application Support.

Rectangular Selection

BBEdit now supports rectangular text selection (when not in soft wrap mode), which is particularly useful for manipulating columnar text. You can cut, paste, and otherwise transform rectangular blocks of text. With previous versions of BBEdit, I would use BBEdit’s regular expression support to work with columnar text, or paste into Nisus Writer or Excel. Being able to stay in BBEdit and do all this with a few quick swipes of the mouse is great. This is not a feature that I will often use, but it’s great when I need it. Mac text geeks know that Nisus Writer is still ahead of BBEdit in that it supports non-contiguous text selection. However, I found that this feature was only useful when working with styled text; BBEdit, being a plain text editor, has no need for it.

Line Processing

BBEdit’s plug-ins for processing lines of text have been reorganized and expanded for version 7. The Cut Lines Containing… and Copy Lines Containing… commands have been merged into a single Process Lines Containing… command. You can choose whether the matched lines are kept or deleted, copied to the clipboard, or copied to a new window.


A new Process Duplicate Lines… plug-in reduces the need for Perl scripting (and adds functionality for those who don’t write Perl) by providing a simple interface for telling BBEdit which criteria to use to find duplicate lines, and what to do with them once they’re found. You can specify that lines be matched using a grep pattern and then use grep sub-patterns to specify the criteria for duplication. For example, you could use the pattern to match fields of tab-delimited data and specify that lines should be considered duplicates if they contain the same values for certain of the fields.


Finally, the Sort Lines… plug-in has also been expanded. It can now send its output to the clipboard or to a new window, instead of modifying the current document. Additionally, you can use grep patterns to specify how to sort the lines, in much the same way as with the Process Duplicate Lines… plug-in. For example, you could specify that tab-delimited data be sorted first by the second field and then by the first field.


All in all, BBEdit’s line processing tools are much improved. There’s nothing the new tools do that couldn’t previously be done by writing a script, but the new tools make common tasks much easier. My only complaint is that entering grep patterns for the tools is not as nice as doing so in BBEdit’s Find & Replace dialog; the text fields don’t use a good code font or provide syntax coloring.


The Glossary holds frequently used text snippets that you can access from a floating palette or by custom keyboard shortcuts. I’m not the type to fill my screen with palettes. Assigning keyboard shortcuts works well to a point—especially since you can re-use keys across different language glossaries. However, I’ve never used the glossary as much as I probably should because of the difficulty in remembering (and typing) the more obscure shortcuts.

BBEdit 7 aims to solve this problem in two ways. First, there is a new menu command called Insert Glossary Entry…. This brings up a list of your glossary entries in a modal dialog. The dialog is fully keyboard navigable, and you can type the first few letters of a glossary entry’s name to jump to that entry. I find this to be a big improvement over the Glossary palette, because it disappears when I’m not using it and because I can keep my fingers on the keyboard.


The other new command is called Auto-Complete Glossary…. To use it, you type (directly into the normal BBEdit window) the first few letters of the name of one of your glossary entries. Then when you choose Auto-Complete Glossary…, BBEdit looks at the letters preceding the insertion point and tries to find a glossary entry with a matching name. If there’s more than one match, it brings up a dialog showing the entries that match what you’ve typed so far.

It’s worth emphasizing that the Auto-Complete Glossary feature requires you to have previously created a glossary entry (a text file in BBEdit Support/Glossary) for the text you want to insert. You type part of the name of the glossary entry (the name of the file) and BBEdit can auto-complete the remaining part of the entry’s name and then insert the entry (the contents of the file). This is quite useful in its own right, but it is completely different from auto-completion in programs like Terminal, Emacs, and Project Builder. In those programs, auto-completion is word-based and works on words in the current window without any prior setup on the user’s part. This kind of auto-completion is not built into BBEdit, but it is available (on OS X) via my free BBAutoComplete utility.

Paste Previous Clipboard

BBEdit has supported multiple clipboards since version 6, and version 7 makes them easier to use. Previously, you could open the Clipboard window to see the contents of all the clipboards (one at a time). You could also use the Next/Previous Clipboard commands to cycle through the clipboards; after each step you could Paste to see what was on the clipboard and Undo if it turned out that you wanted the contents of another clipboard. With BBEdit 7, you can cycle through the different clipboards and see their contents using a single keystroke (Command-Shift-V for Paste Previous Clipboard). After you’ve pasted once, you can simply press this key combination to replace the just-pasted text with the contents of the previous clipboard in the list, and keep pressing it to move further back in the list of clipboards. For Emacs users, this command will be familiar as yank-pop (M-y).


BBEdit now has menu commands for accessing the commonly used features of the Concurrent Versions System. CVS is the version control system preferred by most Unix and open-source developers. It’s used by Apple itself and is included on the Mac OS X Developer Tools CD.

You can add, remove, and commit files from within BBEdit. There are also commands for retrieving revisions from the repository and comparing them using BBEdit’s Find Differences command. You can also get the CVS status of a file and look at its revision history and commit messages. The Find Lurkers… command brings up a BBEdit browser showing a list of all the files in a folder that differ from the current versions in the repository. Finally, there are commands for navigating among conflicts in files that CVS has merged. I used the CVS integration with both local and remote CVS repositories, and it worked without a hitch.


BBEdit’s CVS commands provide convenient access to the basic CVS features, however they are not a complete CVS solution. To create a CVS repository or check out a new working copy, you still need to use the command line or a graphical CVS client like CVL. I don’t consider this a drawback, as such features probably do not belong in a text editor.


BBEdit’s CVS integration is much better than Project Builder’s, both in terms of features and reliability. That said, it still leaves a lot to be desired. The window for entering commit messages is modal, so you can’t scroll through your file as you write your commit message. You have to use the Get CVS Status command to see whether a file differs from the version in the repository. This is easy enough to do, but it would be nice if BBEdit displayed some sort of indicator in the status bar, browser windows, or file group windows. Adding, updating, and committing files works fine, but feels more cumbersome than in Emacs, which assigns the same keyboard shortcut to all three commands and automatically chooses the correct one based on the current state of the document. Find Lurkers… is very useful, but because it doesn’t show the folder hierarchy I often find myself using CVL instead. Also, you can’t select multiple lurkers and commit them together. The Compare Arbitrary Revisions… command is a big improvement over the command line, but it only lets you pick revisions by version number and by date—not by symbolic tag or by commit message. Finally, the Get Revision History command just dumps the revision history in a new BBEdit text window. Again, this is an improvement over having to go into Terminal (or a shell worksheet), but most of the time I find it easier to browse the commit messages with CVL.

Shell Worksheets

Shell worksheets, new in BBEdit 6.5, let you access the command line from within a BBEdit window. The advantages to this are that you have access to BBEdit’s powerful text processing features and that you can save worksheets to reuse the commands later. The disadvantages are that shell worksheets don’t work well with interactive commands, and that they don’t support tab completion or key commands for cycling through the command history. (Emacs’s shell buffers do support tab completion and the command history, and they have much better coloring than BBEdit’s shell worksheets.)

I haven’t found much reason to use shell worksheets, but those who have will welcome the improvements that BBEdit 7 brings. The lower left corner of the shell worksheet window now shows the name of the running command which, among other things, lets you know when the command has completed. There’s now a padlock icon in the status bar, which lets you enable and disable administrator access (think ‘sudo’) on a per-window basis. When you drag files into a shell worksheet, BBEdit helpfully escapes their POSIX paths to make it easier to use them for constructing a shell command. Finally, when a shell worksheet is frontmost, BBEdit’s Open File by Name… command starts its search in the shell’s working directory.


BBEdit now lets you define more than one Web site in its preferences window. Previously, you could only have one Web site defined at a time; people with more than one site had to AppleScript the preferences. Now that BBEdit has real support for multiple sites, the scripting is unnecessary. More importantly, the markup tools are smart about creating links to files in different sites. If you try to link to a file in the current site, BBEdit can insert a relative link; if you try to link to a file in a different site, BBEdit will look up that site’s domain name in your site preferences and insert a full URL.

BBEdit’s syntax coloring now supports ASP/VBScript embedded in HTML as well as PHP4. I have no use for the former, but apparently there are a lot of ASP developers that want to use Macs and BBEdit.

My favorite improvement to the markup tools is the new Close Current Tag command. It does just what the name says; BBEdit looks backward from the insertion point to find the last unclosed tag and then inserts the appropriate closing tag. Between this, the Tag Maker, and the Edit Tag… command, it’s possible to quickly enter and edit tags without having to go into the Markup menu or memorize lots of keyboard shortcuts. Like the other markup insertion commands, Close Current Tag doesn’t give you control over where BBEdit inserts linebreaks; therefore, obsessive hand-coders may prefer to use glossary entries instead.

Notably absent from the list of markup improvements is support for checking the syntax of style sheets. And, of course, many people would like BBEdit’s HTML syntax checker to support arbitrary DTDs. It currently supports the major W3C HTML and XHTML standards as well as Apple’s XML property list format.


There aren’t many documented improvements for programmers. The Open Selection command now lets you enter a colon and the line number. For instance, if a shell worksheet contains an error message that refers to line 42 of the Foo.c file as Foo.c:42, BBEdit can now open the file at the appropriate line. (Similarly you can use bbedit +42 Foo.c from the command line.) What would be better, however, is if BBEdit could make its nice error browser window available for Python and Ruby programmers, and if it could integrate with Apple’s pbxbuild to display compiler messages from Project Builder directly in BBEdit.

I’d rather write code in BBEdit than in Project Builder, but recent versions of Project Builder have some handy features that make programming in BBEdit harder than it should be. BBEdit doesn’t support soft wrapping using hanging indents, nor does it support automatic (syntax-sensitive) code indenting. It can’t find the header file that defines a particular symbol. The Open File by Name command is similar to Project Builder’s Open Quickly, but it’s much slower and it’s hard to choose from among multiple matches. It also doesn’t support filename completion. BBEdit does integrate with the Mac OS X Developer Help Center, but the latter is so poorly written as to be almost unusable.

Finally, BBEdit’s language modules could use some improvement. The common Mac OS X programming languages are well-supported, but the syntax coloring in the shell script module is not very good and there is no language module for Makefiles. Although the existing language modules are of high quality, BBEdit supports only a fraction of the languages supported by Unix editors like XEmacs and VIM. It’s possible to create your own BBEdit language modules, but doing so is much more difficult than with other editors. It’s not possible to extend the built-in language modules, e.g. to add keywords or new languages embedded in HTML.

What Else is Missing

I feel like being harder on BBEdit than other products, because it’s already so good and because so many people think it already has every conceivable feature. In that spirit, here are a few more features that one might reasonably expect a text editor to support, but which are absent from BBEdit.

  • Full support for dark background colors. BBEdit does let you change the background color, but practically speaking you can’t use light text on a dark background because the non-configurable selection color would make selected text nearly invisible.
  • It takes a long time to open very large files (even if you only want to see part of them), and BBEdit can’t edit large files that don’t fit in virtual RAM. Mac OS X supports only 4 GB of RAM, and much less is available to applications. Files larger than that are quite common, and they cannot be opened with BBEdit.
  • When you close a document, BBEdit forgets all the changes you made; you can’t undo them after re-opening the file. Programs like Nisus Writer didn’t have this restriction. Although CVS support and BBEdit’s automatic backups somewhat eliminate the need for this feature, it would still be nice to have.


The new features in BBEdit 7 are welcome additions, as are the subtle interface tweaks like the new tooltips that show you the full names of files in the various palettes. My favorite new features are the CVS integration and Paste Previous Clipboard. Others will probably like the new Web features or the improved text manipulation tools. I’m not jumping up and down, however. Though it’s a good upgrade, BBEdit 7 is simply not up to the standard set by previous paid BBEdit upgrades. Version 5 added improved markup tools and customizable key bindings. Version 6 added AppleScript recordability, multiple glossaries, and file filters. Version 6.5 added Perl-compatible regular expressions, CSS, and lots of OS X stuff. Version 7, at least for my purposes, doesn’t add any such must-have features—though heavy BBEdit users will probably want to upgrade to get all the smaller improvements. Complaints about the upgrade aside, BBEdit is an excellent program. Most Mac users will ignore the Unix text editors, even though they may have more high-powered features, because BBEdit’s interface is excellent and its Macness is unrivaled. It remains the leading example of how the marriage of Mac and Unix can sometimes produce the best of both worlds.

Reader Comments (3)

anonymous · December 20, 2002 - 01:48 EST #1
Pepper still has much better support for different character sets. It's a shame that you can't event set a default character set for BBEdit.
anonymous · March 19, 2004 - 15:01 EST #2
Re: the comment on using light colored text: the text-selection color is changed outside BBedit, in System Preferences / General. So then you have to use that same color across all apps. I find that the Aqua blue crayon is dark enough for white-on-black text, but light enough for highlighting black-on-white text in other apps or the Finder.
saji · June 25, 2004 - 16:38 EST #3
It looks like they added much better Unicode support in 7.0, including support for two-byte languages. 6.5 had inconsistent behavior and didn't allow use of the full functionality with two-byte and mixed languages, so this is a major feature for me.

Add A Comment

 E-mail me new comments on this article