Syntax coloring shoot-out

As a follow-up to the comments on Emacs that I posted earlier, I thought I’d check out how BBEdit is doing lately, seeing as a new version is out (9.1) and that latest I’d seen was 8.7.2.

Well, there’s been big progress in a lot of areas.

Disk browsers and multi-file find results are now much more useful, and on a par with TextMate because you can finally edit files in-place rather than spawn editors in new windows. The interface is still clunky in some ways (the preferences, for example, are overly complicated, and the multifile find suffers from having an overly large initial dialog and a separate results window), but things like the addition of Projects really are a leap forward.

But there’s one area in which BBEdit continues to suck, and badly: syntax coloring. Witness the following comparison between BBEdit, Emacs, and TextMate.

If you look at the sample from BBEdit (below), you’ll see that the text is almost entirely black. You can barely call this syntax coloring at all. Basically the only things colored are are language keywords (if, return), a few types (int, char, long), but notably not others (VALUE, token_t), string literals, and comments.

I personally find this undifferentiated mass of black text to be very hard to look at for any length of time. BBEdit could be the best text editor in the world, and it is a very good editor, but with that syntax coloring I just can’t consider using it.

Moving on to Emacs, and things are literally worlds away (as always with Emacs). It gets the same things right that BBEdit does, but also catches all the types that BBEdit missed, as well as colorizing variable names.

I personally also find the clean, not-antialiased Monaco font much nicer on the eyes, even though the new default font included in BBEdit (Consola Regular) does have a kind of smooth attractiveness. I also prefer the color scheme.

The last contestant is TextMate. It misses out on a couple things that Emacs acts upon (the same types that BBEdit failed to highlight, and variable names), but does do one thing that Emacs didn’t do: highlight function and macro names. I’m not really sure I like the use of boldface for the latter elements, however.

So my personal, subjective ranking of these for both attractiveness and usability is Emacs coming out on top, TextMate a satisfactory second place, and BBEdit trailing far, far behind. And notably, it is precisely Emacs and TextMate which offer the most flexibility for using alternate themes and tweaking things to appeal to your personal aesthetic judgement; whereas BBEdit offers all too few means of addressing its weaknesses (you’re left to tweaking the few color options that are available to you; you can’t actually improve the highlighting at a syntactic level without delving into writing a C plug-in).

Finally, although the sample screenshots don’t show it, I’ve seen a lot more cases of incorrect highlighting in BBEdit than in the other editors, particularly involving quoted strings, regular expressions, and heavy interpolation. I’ve seldom seen TextMate trip up in that area, and I’ve yet to see Emacs trip up at all (although remember, I haven’t been playing seriously with it for long).

Update: 15 January 2009

Adding a MacVim screenshot for the sake of comparison. I’ve been using MacVim for about 120 seconds so the comparison isn’t really totally fair; I’ll post an updated screenshot when and if I find out how to disable anti-aliasing, change fonts, and pick a color scheme that is comparable with the one used in the other screenshots.

But at a glance you can see that the amount of coloring is about the same as BBEdit, with the addition of numeric literals.

Update: 21 February 2009

I finally got around to posting an updated MacVim screenshot with similar colors and font settings.

Update: 30 January 2010

And here we are a year later.

Not much has changed. The only real tweaks of interest are:

• use of more subtle coloring for end-of-line markers
• addition of (intentionally) jarring coloring for long and overlong lines

Update: 5 February 2012

Two years later:

Differences:

• I’m now using Vim in the terminal, generally inside a tmux session
• Now using the incredibly soothing and attractive Solarized color scheme
• Using folding
• Hand-rolled long-line highlighting replaced by Vim’s 'colorcolumn' feature (new in 7.3)
• Current line highlighted (with 'cursorline')
• After a stint with Consolas and a larger font size, I’ve settled on to Monaco, 12 pt, anti-aliased

Update: 21 July 2015

Some three years or so later:

Differences:

• After years of Solarized usage, I switched to the dark "ocean" theme from Base16
• More attractive long line highlighting
• Italic support (even in the terminal)
• Back to Consolas, now 13pt most of the time (and 15pt or more if I’m working with glasses, or on a bus with a bumpy ride etc); once I get a machine with a Retina display I think I’ll take this down a notch
• Still using folding, but less of it

Update: 24 July 2022

(Sponge Bob narrator voice): Seven years later

Differences:

• I got feedback on my screencasts that a higher-contrast scheme would be better, so I switched to "bright" from Base16.
• This on a Retina display, so text is sharper. I use Kitty in some places and iTerm2 in others^[1], and the text rendering differs ever so slightly between those; this particular screenshot is taken on Kitty.
• Font is 12pt Adobe Source Code Pro.
• This is Neovim rather than Vim.
• Overall, settings are tuned for subtlety; for example, I no longer include an eol character in 'listchars'.
• I’m using the indent-blankline.nvim plug-in to show indent markers.

---

1. Why use two terminal emulators? When I got a Linux machine, I needed a terminal emulator for that and went with Kitty. I would have used it everywhere but I ran into some issues on my work laptop (a macOS machine), although I found them livable on my personal laptop (also a macOS machine, but with a slightly different workload, so the problems weren’t deal-breakers). Specifically, I can’t use gh cs ssh to get into a Codespace when using Kitty, and at GitHub, Codespaces is our blessed development platform. So, as much as I’d like to use the same tool everywhere, I figure it’s useful to keep my set-up working relatively well on both emulators, so that I have a fallback option in the future. ↩︎