BBEdit 14, and why you should care

When TextMate burst onto the scene in the mid-2000s, it didn’t take aim at Emacs and Vim as much as BBEdit, a Mac-only editor around more than a decade at that point. TextMate offered radically easy ways to create sophisticated new language modules and plugins compared to most editors of the day. Mostly, though, TextMate had Ruby on Rails: David Heinemeier Hansson developed the framework with early versions of the editor, making it almost custom-built for Rails. That gave TextMate a boost working with other server-side frameworks.

Since then, cross-platform editors and IDEs like Microsoft’s Visual Studio Code and JetBrains IDEs have come to dominate the coding world. This is an issue for those of us who want Mac-assed Mac apps. I hung onto TextMate and then the native-but-weird Sublime Text, shifting to Code somewhat reluctantly. Last year, I pounced onto Panic’s new Nova, reviewing it positively shortly after release.

BBEdit is obviously a Mac-assed Mac app, and for reasons I’ll return to, I came back to it years ago for technical writing—but not for coding. (It sometimes seems like BBEdit’s biggest fans are writers.) Some more code-focused users, though, haven’t looked at it in years. With the release of version 14, should they reconsider?

Musty, or battle-tested?

Few editors have been around longer than BBEdit—and few have been as rock-solid. I don’t think I’ve ever lost work. It can even “rescue” never-saved documents you mistakenly close without saving!

Yet, that venerable age has become a double-edged sword. “Looks old” is a dismissal I’ve heard a lot. I’ll be honest: to me, it looks like…a text editor.

Screenshot of BBEdit 14
BBEdit 14, editing HTML.

It’s information dense, but neither overly busy nor packed with unnecessary bits. (Nearly everything shown here can be turned off, too.) One thing you don’t see? Tabs. Instead, there’s an open documents list in the sidebar. If you end up with a dozen or more files open at once, this approach starts really showing its advantage.

Leaping forward

Here’s something cool:

A snippet of PHP code showing autocompletion in an editor
A language server at work.

This editor understands PHP well enough to know that after you type $handler->, it should offer methods from the Handler class as autocomplete options, because it knows $handler is an instance of that class.

This level of introspection used to be the exclusive domain of IDEs, but a couple of years ago, Microsoft introduced the Language Server Protocol for Code, so plugins could offer this functionality. Nova supports LSP natively, and with version 14, so does BBEdit. In addition to smart autocompletion, BBEdit uses language servers for:

  • Function parameter help
  • Real-time code linting
  • Navigating to function definitions and symbol declarations
  • Reformatting documents

See the green dot in that screenshot? It’s a dropdown for showing errors and warnings in a file. Individual lines also get their line numbers highlighted and the issues shown by underlines. (The snippet above shows $response with a red underline in two occurrences: the first because that line isn’t complete and so has a syntax error on it; the second because, thanks to the first error, $response isn’t defined yet.)

BBEdit is preconfigured to use many language servers, like Intelephense, out of the box once they’re installed. This can be considerably more complicated in other editors, especially if their LSP support is itself provided by an extension.

A couple of caveats: first, a lot of language servers apparently haven’t been tested with anything but Code, and can get quirky with any other editor. Sometimes BBEdit can work around quirks, but not always. Second, BBEdit doesn’t support all LSP features. For instance, documentation won’t pop up when you hover your pointer over a function or symbol.1

Other new features

BBEdit 14 now has a “Notebook.” This takes the already-existing “scratchpad” feature (itself unique to BBEdit) a step farther, storing multiple notes as individual sheets within an always-available Notebook window. By default, BBEdit creates notes as Markdown files, but you can change them to other languages. As with any text file, you can create new notes from the clipboard or from selected text, by dragging text, or even from the shell by piping text to bbedit --note.

I haven’t played with the Notebook much yet. It strikes me as the kind of feature you’re either going to rarely use or use all the time, and it’s not clear to me where I’ll fall. I use scratchpads a lot, though, and have a weakness for note-taking apps. I could imagine putting together a package that offered some basic to-do list functionality that might effectively replace TaskPaper, too. It’s not Emacs’s legendary Org mode, but then again, it doesn’t make you learn Emacs.

Beyond that, BBEdit now supports Emmet for HTML and CSS expansion if you install the Node Emmet module; if you make from-scratch HTML pages a lot, this is a big deal. If you’re a Python programmer, BBEdit is now aware of Anaconda/Conda virtual environments out of the box, and lets you switch between them with its shell menu.

Other old features

When I became a full-time technical writer in 2014, I tried a few different editors and settled on BBEdit, even though its Markdown syntax highlighting is…spartan. Why? Because BBEdit is a Swiss Army knife, a Leatherman multi-tool, for text processing. In no particular order, here’s some interesting things BBEdit does that I rarely see in other editors.

  • What it lacks in Markdown highlighting, it makes up for in Markdown previewing. You can set custom HTML templates, CSS files, and even processing scripts. (You can do this for HTML files, too, and I suspect for other kinds of plain text markup languages.)
  • Many editors have a “fuzzy file open” feature, but BBEdit can open multiple matching files simultaneously. I use this way more often than you might think.
  • BBEdit keeps a history of find/replace searches, and lets you save complex grep patterns with names for easy recall. And you have to see its “Multi-File Find” feature to fully appreciate how great it is.
  • You can build a “text factory” of multiple actions; it’s like having a simple version of Shortcuts or Automator built right into the editor. You can save them as text filters or use them for batch processing. I have a simple-minded Markdown to BBCode conversion “script” I created this way without writing a line of actual shell script.
  • You can “process” lines in a file, searching for duplicates or lines that match specific patterns (including regular expressions), and delete those lines, copy them to the clipboard, or create a new document with them.
  • BBEdit can operate on “columns” of tab-separated values, cutting, copying, pasting, and even rearranging them.
  • While Git support is mostly (ahem) bare bones, it’s fantastic with file-specific commands like diffs and revision history.
  • The “Pattern Playground” is outstanding for constructing complicated regular expressions that work with your documents.
  • BBEdit uses Kapeli’s Dash documentation browser if it’s installed.

The Unix Worksheet in BBEdit deserves its own paragraph. Send any line in the worksheet to your shell by tapping Control-Enter, and the output from the shell appears under that line in the worksheet. You can’t run interactive shell programs this way, but for most commands you now have an editable, modifiable history. In my technical writing, I create lots of local branches; I usually use a worksheet to clean them up by running git branch to get a list of them, then adding git branch -d before each one I no longer need. The worksheet is inspired by the long-defunct MPW, but Emacs fans might consider it a cousin of shell mode.

Lastly, another feature of BBEdit worth checking out: the 400-page user manual. Yes, that is what a technical writer would say, but it’s a remarkable boon.

A few missing features

BBEdit has a more “batteries included” approach than most editors, and so needs fewer third-party extensions. But, the integrated managers in Code and Nova make a strong argument for a centralized package index. Sublime Text’s Package Control started as a third-party system, so it’d be possible for someone else to take up the mantle here. The closest BBEdit has is BBEdit Extras, and while it has some good stuff, it’s also got a lot of outdated (and frustratingly undated!) stuff and an awful lot of link rot.

Sublime Text popularized multiple cursors in text editors. BBEdit’s processing commands can do nearly anything these can—honest—but if you’re a multi-cursor junkie, it’ll be an adjustment.

Codeless language modules only set colors for strings, comments, keywords and “predefined names,” along with delineating functions for navigation and folding. CLMs also can’t be used for templating systems like Jinja or EEx that exist as “embedded languages” in HTML. You can write a more powerful language definition in Objective-C—I presume including templating languages, since “PHP in HTML” and “Ruby in HTML” are standard—but that’s a hella big ask.

Back to the future

I’ve long believed that BBEdit’s balance of text processing power with discoverability and ease of use makes it the best tool for “documentation as code”-style technical writing on the market. But at least for me, it hadn’t kept up with the state of the art for coding. With BBEdit 14, this no longer feels true.

So, I’m moving back. I’ve created a new color scheme, SpaceBones, inspired by the default color scheme of Spacemacs. I’ve been working on an up-to-date package for Elixir that comes with an LSP, as well as creating a new set of clippings for PHP 8. My old Editor Actions package may get a reboot. Hopefully, there will be ways to publicize these; I’d love to see a BBEdit-focused project similar to Vim Awesome.2

If you’re already a BBEdit user, version 14 is an essential update. If you’re not—whether you used it years ago but drifted away, or never used it at all—it’s time to give it another look.

BBEdit 14 is $49 new from Bare Bones Software, with upgrade discounts for owners of earlier versions, or from the Mac App Store with a $39/yr annual subscription. You can use BBEdit for free with a more limited feature set. Disclosure: I beta-tested BBEdit 14, and received a free upgrade serial code.


  1. Although some might argue that is more feature than bug. [return]
  2. Ironic detail: Vim Awesome is built on RethinkDB, a document-store database whose documentation was primarily written—by me—using BBEdit. [return]

Panic’s Nova, ten months in

TL;DR: I’m not using it much.

I’m sure my review of Nova made it clear that I wanted to like this editor a lot. In practice, though, it’s felt more like its predecessor Coda and a similar competitor of Coda’s era, Espresso, than like Visual Studio Code or BBEdit: targeted chiefly at web developers mucking about with static websites. (Which, to be fair, is a sizable audience; my website is static, and Nova’s pretty good with it.)

Nova’s built-in smart autocompletion hasn’t proved particularly smart when I’ve been using it, which in some ways makes it more frustrating than not having it at all. Backing it with a language server theoretically improves it, but Nova’s LSP support is fragile and weird. I don’t mind it being somewhat incomplete, but it’s entirely dependent on third parties writing extensions that talk to language servers—which would be fine if they worked. But at least in the languages I use, they don’t. For PHP, there are two wrappers for Intelephense; one just flat out doesn’t start, and the other one makes Nova crash on startup. For Elixir, the elixir-ls extension works in the sense of, you know, not crashing, but mostly what it seems to do is hover huge documentation pages over the screen if the mouse pointer rests over an Elixir keyword. (I have heard Nova’s TypeScript extension is solid, but I haven’t tried it.)

Beyond that, when it comes to the basics of just editing, Nova is…fine? It does the job. But—like Coda and Espresso—it doesn’t have the selection and manipulation chops of higher-power editors. I still have no idea what commands like “Select All in Any Scope” are supposed to do because they’ve never worked. Nova’s clips are useful, but limited compared to the equivalents in BBEdit or Code (or any editor, like Code, that basically adapted TextMate’s snippets).

So, am I going to renew for the $49 annual subscription? I haven’t entirely ruled it out, but, well, it’s not looking good. I’ve been spending much more time back with BBEdit recently…but that’s another article.

The Mac and the iPad aren’t meeting in the middle yet

At the end of 2010, John Gruber of Daring Fireball wrote in a Macworld column,

The central conceit of the iPad is that it’s a portable computer that does less—and because it does less, what it does do, it does better, more simply, and more elegantly. Apple can only begin phasing out the Mac if and when iOS expands to allow us to do everything we can do on the Mac. It’s the heaviness of the Mac that allows iOS to remain light.

Back then he wrote that long-term (“say, ten years out”), iOS might replace macOS. But in 2020, Apple recommitted to the Mac: the Mac Pro, the return of good keyboards, and—the biggest move yet—a new CPU architecture designed in-house.

Since then, I’ve seen a chorus of pundits, both professional and armchair (hi), push two theories that are either at odds or entwined, depending on how you look at them:

  • Surely, a dystopian iOS-like future of only sanctioned App Store purchases lies ahead for the Mac. (Let’s call this the “Hacker News bait” narrative.)
  • Surely, the iPad is going to catch up or even surpass the Mac—it already does so many things so well, and it’s only held back from its potential by an OS with artificial limitations.

The Hacker News bait narrative is bullshit. But I’m not sure about that second, sunnier one, either. Apple has been demonstrating a consistent philosophy for over a decade:

  • Macs are general purpose computers.
  • iPads and iPhones are application consoles, analogous to game consoles.

These have been true from the beginning of each platform. Macs have always been general purpose computers, and iPhones and iPads have never been such.

There’s no intrinsic reason iOS devices had to be consoles; other smartphones like Windows Mobile and PalmOS phones weren’t. We all know that, but we forget that there’s also no intrinsic reason Macs had to be open. Not only was its direct antecedent the Xerox Star considerably more console-like, so was Jef Raskin’s original concept for the Macintosh, which evolved into the Canon Cat. Yes, if the Mac had been positioned as an appliance the way the Star and the Cat were, it would likely have joined them in obscurity—but we say that now with nearly four decades more “common wisdom” about computers. The Cat wasn’t the only early attempt at an application console; the 1990s saw the Sony eVilla and other “Internet appliances.” Those products didn’t fail because the concept was bad; they failed because the technology to support the concept just wasn’t there yet. A decade later, we had small, lightweight touch screens and widespread high-speed wireless data—and internet appliances became possible.

As long as this philosophy on Apple’s part holds—and there’s no evidence that it’s changing—macOS will never be locked down to the degree iOS is, i.e., unable to install non-App Store apps without jailbreaking. But the Venn diagram of “users likely to walk over such a drastic change to the Mac” and “users likely to spend boggling amounts of money on Apple hardware” is close to a perfect circle. Apple would have to not only make up the lost hardware revenue in App Store revenue but beat it. You need 30% of a hell of a lot of apps to make up for a single lost 16-inch MacBook Pro sale, let alone a Mac Pro. Even if it was just four or five percent of users—and I think that’s extremely optimistic—that’s millions of lost unit sales, and likely forgoing entire markets the Mac currently has a meaningful presence in. There’s just no business case for such a move. Beyond that, given all the radical changes Apple made to the Mac in 2020, it feels like that was the “now or never” moment. If M1 Macs and macOS Big Sur didn’t lock us into an App Store-only world, it’s pretty unlikely macOS Pismo Beach or whatever is going to.

But that brings us to the second point. Is this the year when the iPad does get to do everything, not just most things, the Mac does? Will we be able to run macOS apps on M1 iPad Pros the way we can run iOS apps on M1 Macs?

I do think Final Cut and Logic will come to the iPad eventually in some form. But so far, macOS has remained a general purpose OS, and iOS has remained a console OS—and I don’t think that’s changing soon. I just don’t. I’m doubtful that Apple has any interest in getting an Xcode-like iPadOS development going, and doubtful they plan to “open up” iOS any more than they must for technical, market, or regulatory reasons.

Yet on an infinite timescale, this dichotomy can’t hold. It may be a minority of people who truly can’t do their work on the iPad, as opposed to just kvetching that they can’t do it the same way as they do on a Mac or a PC. But that minority is there, and they matter.1 So the question is what happens to break it and when. I’m expecting iPadOS 15 to have some major UI changes, possibly even the first tiling window manager designed for humans. My pie-in-the-sky guess is that a new operating system replacing both macOS and iPadOS is already underway. Its foundations are Swift and SwiftUI, and macOS Big Sur and iPadOS 15 are early bits of scaffolding. The Mac gets lighter; iOS gets heavier. But they’re not meeting in the middle yet.


  1. As a technical writer, I’m actually in that minority: not only am I expected to be able to do local preview builds of the documentation web site I help edit/maintain, no iPad text editor I’ve tried comes close to BBEdit for working on projects with thousands of Markdown files. [return]