Month: May 2005

Review: BBEdit

This has been brewing for a long time. I’ve been a BBEdit user for a long, long time (over ten years) so it’s a piece of software I know really well. And when there’s an update, I always bump into the reviews on MacUpdate or VersionTracker. And a lot of those reviews just strike me as wrong in a variety of ways, so I wanted to offer my (highly-opinionated) take.

The most common criticism of BBEdit is that it’s expensive. $179 is indeed a lot of money for a text editor. The thing about it is that I spend an awful lot of time editing basically raw text, and I bet most computer users spend more time doing this than they realize. It’s not unusual for me to handle raw HTML (which I want to mirror to an FTP server), a shell script, a post or two on a Web forum and some kind of tab-delimited data file all in the same day. Then there’s the occasional something weirder, like maybe a LaTeX or Python source file on a CVS or Subversion repository. Or maybe I want to crack open a raw XML file to see how it’s structured or what some of the contents are. Oh, and of course sometimes I want to compose email not in my mailer to make sure I don’t send it out without thinking about it for a day or two first. (Don’t divert me on the nonsense of styled text in email.)

So, first there’s HTML. One of the most inane criticisms I’ve ever heard is that BBEdit isn’t a WYSIWYG editor. Yes, that’s right, it isn’t. In fact, there is nothing which is really a WYSIWYG HTML editor! That’s because your precious HTML will be rendered by different browsers with different screen resolutions, window sizes, font and font size settings, and even underlying rendering engines. (Side comment: If you’re trying to micromanage all these things for the user, you’re doing him/her a huge disservice and wont’ succeed very often anyway.) So this is a stupid criticism. If you want to know what the file will look like in a particular browser, open in it that browser. I probably have five or six browsers on my machine at any given time–why do I need my editor to have an HTML rendering engine in it? Of course, one motivation for this might be workflow-related, not wanting to go out to the file system and drag the file to the Web browser. Well, BBEdit has commands for rendering the current file in a browser, or even all the browsers on your machine–and this command, like all commands in BBEdit, can be bound to whatever keystroke you want. So much for WYSIWYG workflow.

BBEdit’s ability to support HTML is truly outstanding. I learned good old HTML 1.0 in like 1994 (egad) and I still edit the tags directly. But I find that I don’t always remember the syntax for tags which weren’t around “back in the day” and I certainly never remember the hex codings for colors other than black and white. BBEdit gives me context-sensitive, single-keystroke access to dialogs which understand the tags (and do the Right Thing based on the DTD at the top of the file if it’s there) and remind me of the syntax and give me popups for things I don’t remember like color. It also has great CSS support (a real boon to those of us who get the idea, but never bothered to learn all the syntactic details). SubEthaEdit and some of the other free/cheap programs are great, but I’ve not seen anything close to this in any of them. (Disclaimer: I don’t do PHP–yet–so I can’t say how well it supports that.) Things like being able to save a copy of the current file (I like to have one local copy and one on the server) directly to an FTP server without leaving BBEdit is just icing on the cake–and I love icing.

Of course, the reason I started using BBEdit in the first place (circa version 2) was to edit C code. Well, I never program in C anymore (too low-level) but I do write occasional shell scripts and Python code and every once in a long while I need to read C or C++ code. BBEdit is a great programmer’s editor, with terrific features to support this activity. Most such features are now pretty common in alternative programs such as function popups and syntax coloring, but like the HTML tag editors, I’ve never seen a “diff” which even comes close to BBEdit’s. And if you can’t see where a really good diff would be useful, you need more hours programming. Built-in support for CVS and Subversion also greases the wheels on things like this. BBEdit also has very good integration with the underlying unix of Mac OS X and is a terrific environment for shell scripting, which is useful for me because I’m a bit rusty not having done much of this since grad school (though I’m happy to have it available again).

I also spend a fair amount of time munging data files generated in my lab. These are almost always tab-delimited text files, and are sometimes fairly large. Commands for processing duplicate lines and lines which meet a specific criterion are extremely useful in this context. This is where BBEdit’s excellent support for regex-based search-and-replace is really key. If I want to look at a specific data pattern and clip out all lines which contain that pattern across hundreds of files, it’s easy to do this in BBEdit. I have yet to see this be made easy by any other GUI-based editor. (I suspect some form of emacs can do this, but I never got too into climbing the emacs learning curve.) One of the critical pieces of this functionality is BBEdit’s terrific AppleScript support. Programming your text editor may seem like a weird thing to do, but BBEdit has a lot of the right primitives for doing a lot of the things I want. Some of those things would be done probably almost as easily with things like Perl (which I haven’t bothered to learn yet because the syntax violates my aesthetic sense so badly) or Python, but I’ve been using BBEdit to do those things for so long that they seem more natural to me in BBEdit, plus I don’t have to burn any code on things like selecting only certain kinds of files or subdirectory traversal, since all that’s built in. Cheap alternatives like TextMate have some nice features, but they lack this. (Note: TextMate’s macros are nice, but I strongly prefer my recorded actions to be handled in AppleScript so I can call them, or parts of them, from other apps.)

There are all kinds of other cool things in BBEdit that I use all the time. One of them is the “change case” command. I could not count the number of times I’ve opened BBEdit just to paste in some text and munge it with the “change case” command only to copy and paste it back somewhere else. A small thing, I know, but small things add up over the years. Another thing I bump into all the time are line endings, now that Macs are split-personality old-style machines with some files having Mac line endings and some with unix line endings. BBEdit handles this in an elegant way, and most importantly, is scriptable.

The other common complaint is that BBEdit is becoming “bloatware.” Well, yes, there are a lot of features and menus and the menubar is pretty long if everything is enabled. But unlike Micro$osft Office, which is the poster child for bloatware, I actually use a great many of the features in BBEdit. I admit I probably under-utilize some of the powerful features others rave about–I don’t make as much use of the Glossary as I probably could–but I really do find that many of the features are, in fact, things that once I get my head around what they are, I find them more useful than not. And if you don’t use CVS or Subversion or Text Factories, you can turn those menus off. OK, yes, there are 31 commands in BBEdit’s “Text” menu, but I can honestly say I’ve actually used every single one of them. I can certainly see, though, how someone just downloading the demo to check it out might find the plethora of menu options and preferences somewhat daunting. But there’s a reason for all of it, or nearly all of it, at least for me.

Have there been bumps in the road? Sure, there are occasional BBEdit versions which are a little glitchy (8.0 comes to mind, though I can’t even remember what small weird problems I had). But BareBones releases bug fixes quickly and is more responsive to customer input than any company I’ve ever seen. If I send email to the president of the company, I not only get a thoughtful answer, but he remembers who I am. Wild.

So, yes, BBEdit is expensive and has an awful lot of stuff in it. Those two things are related, but in my mind, related in a positive way. Of course, I’m academic and I’m pretty much only paying for upgrades anyway. Regardless, I’d pay full price out of my own pocket to keep this application around. It’s just about the only application which I have launch at login, because I know that if I’m going to use my machine for more than 20 minutes, I’m probably going to use BBEdit.

Now, having said all that, there are a few things I’d still like to see in BBEdit, but none of these are show-stoppers:

• Live, or as-you-type, spellchecking. The current version (8.2.1) of BBEdit has something kind of close, but it’s still not what I want because I still have to remember to invoke it.
• Specific support for editing vBB/UBB-style tags. Yes, they’re stupid, but some forums use them and won’t take HTML. Too specialized and stupid, I know.
• TextFactory menu and Subversion support. Oh, wait, those are the things I asked for in version 8.1 and now I have both. Never mind.
• Code/section folding. In my mind, lack of this is the most legit criticism on the boards. This is one place where TextMate does have a real advantage. I’ve wanted this ever since I saw the some early prototype of the Dylan IDE (don’t ask) in like 1991.
• Oh, there’s another cool feature in Smultron I’d like to see, which is .Mac syncing of preferences (and things like grep patterns and such).

The “Business Drone”

I travel for work a fair amount—not a huge amount but I generally log around 30K miles/year—and it’s interesting to peoplewatch in airports and on airplanes. I’m not an anthropologist, but I’ve come to identify a particular species of traveler, which I now identify as the “business drone.”

The business drone can usually be identified first by dress. He (and they’re almost always men, for reasons I haven’t yet figured out) is generally attired in slacks, dress shirt and tie, and usually not especially comfortable shoes (which may cause some of the characteristic behaviors). A cell phone is a required accessory, with a Blackberry increasingly part of the ensemble. Laptops are common but not universal. Business drones tend to be middle-aged but there are occasionally younger examples of the species. My suspicion is that the bulk of the species are middle management.

Typical behaviors of the business drone? First, many business drones fly first class, probably mostly on mile-based upgrades. Those that do not clearly expect the flight attendants to treat them as if they were in first class regardless of seating. Drones have certain characteristic boarding behaviors, such as generally trying to board the plane before their row is called. Carryon luggage also generates certain patterns. If the carryon is one of those rolling bags carefully engineered to be exactly the maximum allowable size (which seems reasonable), which can stow front-to-back in an overhead bin on many planes (thus taking up less usable space), no effort is made to orient them front-to-back. A common variant is the garment bag, often of questionable permissibility in terms of size, which, even if other options exist, must be stored horizontally on the bottom of the bin, taking up maximum possible space.

Once baggage has been stowed and a seat taken, the drone will then generally either take out his laptop or, more commonly, initiate a cell phone conversation. Use of this device is somehow privileged and continues after the request is made over the loudspeaker for such usage to stop. A second request made directly by a crewmember, however, is generally effective. Cell phone conversations must be held at a volume sufficiently high that anyone within a few rows is forced to endure the conversation. Common conversation topics include office politics (with obvious sucking up not unusual), attempts to re-jigger travel schedules, and postmortems on meetings. Any levity in such conversations is so obviously forced that surely the drone suffers physical pain. Communications with family are surprisingly rare.

Once the flight is underway, if the drone is lugging a laptop and chooses to use it, activities are typically limited to solitaire, review of PowerPoint presentations, and less frequently, browsing of spreadsheets. Activities which involve significant use of the keyboard/brain complex (e.g., writing, programming) are exceptionally rare; the laptop appears to be more of a status symbol than a functional object. Desktop backgrounds are generally either one of the standard Windows backgrounds or something corporate. Things like photos of family or even vacations are unusual. A recent development is the use of the laptop as a DVD player, but I have not yet noticed trends in film selection.

Non-laptop activity is generally reading. Review of business documents is common but not universal; recreational reading is just as common. Newspapers are the top choice, with the Wall Street Journal leading the way. General news magazines (e.g., Time) are not uncommon. Novels do also appear, with strong preferences for the male-oriented segment of the current bestsellers’ list; Tom Clancy-type novels are particularly favored.

Being a headphone geek, I do notice the cans worn by drones, if any. And if any head-fi types wonder who’s buying all that overpriced but well-marketed Bose product, it’s business drones. Triports and QC2’s are popular choices of this crowd.

At the end of the flight, shutting down of electronics is often done with similar reluctance. When deplaning, willingness to yield to other travelers with tight connections or other extenuating circumstance (mild disability, old age, children) is limited, generally near or at zero.

OK, can you tell I’m traveling today?

GM to Junk Bond Status

(fark thread reply, 2005.05.06)

neofonz has the right general idea: GM is such a big mess, there’s more than enough blame to go around. Unions are neither the sole or the worst cause, but come on, even the most pro-union people have to see some culpability here. And the health insurance mess is certainly part of the problem, but GM isn’t the only company who deals with this issue and all the other ones didn’t suddenly go to junk bond status. Shortsighted execs who have for years let the bean counters have dramatically more say then actual design engineers, resulting in a generally horrible product line (with some exceptions, sure, but mostly, yuck) also deserve a big chunk of the blame, too.

There is no one single, simplistic cause–ALL of these factors have been brewing for years, and it’s finally come to a head. Frankly, I’m surprised its taken this long; I’ve been expecting this since 1991 when I drove literally everything in GM’s entry-level (non-truck) lineup and without exception, they all sucked badly. GM didn’t give a rip about good design or build for reliability then and I haven’t seen (much) change since.

The one group I would NOT blame, though, is the U.S. consumer. For most consumers, a car is the second-largest purchase made besides a house. Why should consumers shelling out five figures of their own money be required to buy an obviously inferior product? (This might not apply to trucks, I don’t know, but for entry- and mid-level sedans, GM has been producing an incessant line of crap for years.) To maybe save the pension of some anonymous factory worker who makes $25/hour for putting on screws and lives a thousand miles away? What’s that factory worker going to do to save my job if its threatened? Do any UAW-protected employees shop at Wal-Mart? I think the whole “buy American” thing is just an attempted guilt trip by GM/Ford to try to get American consumers to accept products they know to be worse. I’ll spend my money on what I think is the best use of my resources for my family, thank you very much.