{"id":52053,"date":"2026-06-01T14:47:22","date_gmt":"2026-06-01T18:47:22","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=52053"},"modified":"2026-06-01T15:04:52","modified_gmt":"2026-06-01T19:04:52","slug":"bbedit-16","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2026\/06\/01\/bbedit-16\/","title":{"rendered":"BBEdit 16"},"content":{"rendered":"

Bare Bones Software<\/a>:<\/p>\n

\n

This release of BBEdit introduces expanded support for macOS “Shortcuts”, via additional actions provided in the Shortcuts application. A “Transform Text” operation allows invocation of “one shot” operations of many kinds, and transforms are provided for extracting matching lines, deleting matching lines, sorting lines, and text replacement.<\/p>\n<\/blockquote>\n\n

The shortcuts can either interact with the front document or use BBEdit as a headless text processing engine (without having to launch the app). This is great news for Shortcuts fans, as it’s now really easy to receive text, operate on it, and send it along to the rest of your shortcut. Personally, I’m not a fan<\/a> of locking logic away in the Shortcuts database. I would be more inclined to use a text factory or AppleScript. Text factories provide more options and a better interface than is available in Shortcuts, and both text factories and scripts can be saved as standalone files and easily reused in other contexts (from within BBEdit or other scripts).<\/p>\n\n

\n

Added support for using the W3C HTML checker service. This is on by default, and improves the correctness and accuracy of syntax checking in HTML5 documents.<\/p>\n<\/blockquote>\n\n

Most of my projects are embarrassingly still HTML 4, but in some limited testing I found that this worked as expected. By default, it works online, which felt plenty fast and presented the results in the familiar BBEdit errors browser window. (I love how, unlike in Xcode, errors and search results are in separate windows that you can keep open.) They say that the connection to the W3C is secure and that no data is retained, but it’s also possible to install a local copy of the checker for maximum privacy.<\/p>\n\n

A longstanding issue for me is that a lot of my HTML pages contain dynamic elements inserted by PHP or Python on the server. The local files that I edit in BBEdit are either templates, content that will go into templates, or statically rendered pages with a few pieces still missing. In order to check the final versions of these pages, I can use a bookmarklet for the W3C checker or load the final HTML and send it to BBEdit for analysis. This can be done by using an AppleScript<\/a> to send the source from Safari or by loading the page using BBEdit’s Open File By Name<\/strong> command. BBEdit can also check for broken links, but this is for links to files within the local copy of a site you’re editing. It won’t check remote URLs. If I try to check a page from this blog it will complain about all the links that are just path references because they aren’t stored locally (or, indeed, anywhere except in WordPress’s cache).<\/p>\n\n

\n

BBEdit can search for text in images, via OS-provided image text recognition. Use the Find or Multi-File Search windows to search for (and extract, if desired) matches for a given string or Grep pattern within image files.<\/p>\n<\/blockquote>\n\n

This is really cool. Spotlight has had image searching for a while, but it’s much more useful in BBEdit. You can do more precise searches, finding case-sensitive or regex matches. The matches are presented in the aforementioned standard results window, so you can see all the files, as well as the context around the matching text, in one list.<\/p>\n\n

The use case that immediately came to mind was searching through screenshots, e.g. in documentation for my apps. I also found it useful for finding text in memes and for searching for ski trails in my folder of maps. It was able to find trail names where text was curved or at an odd angle, and it highlighted the matching region of the map in yellow. When there are multiple matches, you can arrow-key through them and watch the highlight move.<\/p>\n\n

Text and image files can be part of the same search, and the performance is impressive. I mostly just leave image searching on, but there were a few cases where I was searching a big folder and knew I didn’t need image results, so I turned off image searching to make it go faster. The multi-file search window now makes it easier to see at a glance whether options like this are enabled.<\/p>\n\n

\n

Added settings to projects, instaprojects, and notebooks for project- (and notebook-) specific color scheme settings.<\/p>\n<\/blockquote>\n\n

I tend to use different color schemes in different apps<\/em>. It’s hard enough to find ones that I like, so I certainly don’t want to create more. But judging by the reactions I’ve seen, people really do want to create multiple color schemes within the same app to quickly tell apart different projects.<\/p>\n\n

\n

Added controls to allow use of an alternative color scheme when\nprinting, if desired. The default is to use the document’s\ncurrent color scheme, but if you routinely work in Dark Mode\nand<\/em> print things out, selecting an alternative color scheme\ngenerally provides a better outcome.<\/p>\n<\/blockquote>\n\n

I don’t use Dark Mode, but this makes a lot of sense. I already had it set to use a different font for printing.<\/p>\n\n

\n

Keyboard emulation for vi<\/code> is available, via the corresponding\nsetting in BBEdit’s “Keyboard” settings. This enables a basic set\nof vi<\/code> navigation and editing commands and modes. :q<\/code> will\nclose the active document rather than quitting BBEdit.<\/p>\n<\/blockquote>\n\n

Personally, I prefer the Emacs keybindings, and there’s good news on that front, too. There’s been a longstanding bug where Control-N (to move down a line) would sometimes stop working. It was a really strange issue that I could never figure out exactly how to reproduce, and it only affected that one Emacs key. BBEdit 16 now supports the Cocoa-standard DefaultKeyBinding.dict<\/tt> file. I added a \"^n\" = \"moveDown:\"<\/code> line, which is redundant for NSTextView<\/code> apps that already have it built in, but for BBEdit it seems to sufficiently override whatever code path was intermittently failing, so now the key works consistently for me.<\/p>\n\n

\n

Added a button to the Languages preferences for installing a desired language module. This will handle copying of the language module to the appropriate location; so any obsolete instructions regarding where to copy the module can be ignored.<\/p>\n<\/blockquote>\n\n

The interface for languages and their settings has been overhauled a bit and overall works more smoothly now. There’s also now a nice interface for importing and exporting grep patterns, so you don’t have to dig into BBEdit’s files.<\/p>\n\n

\n

The file information panel (via “Get Info” or the document status icon in the navigation bar) adds an indicator when the file has been quarantined by macOS. The adjacent “Clear” button will attempt to remove quarantine.<\/p>\n<\/blockquote>\n\n

This is one of those minor features that is technically not needed, because I can easily do it from Terminal. But it’s annoying, and whenever I do it I think I should probably write a script to remove the quarantine on the front document. I never got around to that, but now I can just click a button. Also, if you haven’t checked out the info panel in a while, besides showing the basic file stats it can also adjust file permissions and show Spotlight metadata.<\/p>\n\n

\n

Expanded syntax coloring support, via the Language Server Protocol “semantic token coloring” feature. When supported by the language server, this allows the server to provide information on specific ranges of the source code that supplements BBEdit’s built-in syntax coloring for the given language.<\/p>\n<\/blockquote>\n\n

I still love the idea of LSP, but it hasn’t quite lived up to my hopes yet. The usefulness probably varies greatly based on which language you’re using. These days, I mostly write Swift, so I’m comparing with the functionality that’s built into Xcode. The main problem is that Apple’s SourceKit-LSP doesn’t support Xcode project files. In order for LSP to find your dependencies, you have to run a script<\/a> to create a compile_commands.json<\/tt> file and\/or install xcode-build-server<\/code> and set up a buildServer.json<\/tt> file. It was never fully clear to me what I was supposed to do. Of course, my projects also have Objective-C files and Swift code that extends Objective-C classes, so clangd<\/code> is in play, too.<\/p>\n\n

I got it working to a certain extent but never to the point where it would find all the files it needed in Apple’s frameworks, my own frameworks, and the related files in the same target. So the display of the compiler errors\/warnings just wasn’t useful when editing files in my projects. I’m not sure whether this was due to bugs\/limitations of SourceKit-LSP or user error. BBEdit’s LSP features do work very well for standalone files with no dependencies, e.g. if I have a test file to explore an API or I’m writing a “script” in Swift.<\/p>\n\n

Setting aside the compilation errors, I do find the new semantic token coloring helpful. It’s not as good as Xcode’s, which can use different colors for local and instance variables. And there are some issues with the coloring of unknown symbols and with local variables sometimes changing color between definition and use. But I prefer it to the basic syntax coloring.<\/p>\n\n

Code completion is a mixed bag. Sometimes it works really well, basically like in Xcode. Other times, it won’t complete because it hasn’t found my dependencies or because AppKit was an implicit import rather than listed at the top of the file. I sometimes wish there were a way to turn off LSP completions (without turning off the rest of LSP) and just use the regular, lower-tech BBEdit completion engine that’s more reliable.<\/p>\n\n

A pleasant surprise is that the Edit ‣ Show Symbol Help<\/strong> command is often more<\/em> reliable than Xcode at showing the inferred type for a variable.<\/p>\n\n

\n

Added a command to the View menu and to the contextual menu in the sidebar: “Move to Window…”. This opens a dialog in which you can choose an extant window for the active document (or selected sidebar documents, as appropriate), and upon confirmation moves the document(s) to the designated window and makes it active. A search box is available to filter candidates.<\/p>\n<\/blockquote>\n\n

I love how this can be completely keyboard-driven.<\/p>\n\n

\n

Enhanced the Unicode display section in the Character Inspector palette to show the Unicode code point names for the respective characters.<\/p>\n<\/blockquote>\n\n

You can select a range of characters, and it will show the hex code points as well as the names. This is really handy for breaking down complex characters into their parts. Emoji display within text windows has also been improved.<\/p>\n\n

\n

The Minimap palette gets a cursor position display, and a popup menu button displaying the name of the function containing the start of the selection range. Clicking on the function display will open a function menu, from which you can choose another location in the displayed file.<\/p>\n<\/blockquote>\n\n

These are good improvements, but I still find the Minimap much less useful than Xcode’s, which shows some section headings directly in the map and lets you browse others by hovering. The other main editor features that I miss from Xcode are multiple cursors and syntax-aware indentation.<\/p>\n\n

\n

Git revision lists (as used in “Compare Revisions”, “Compare Arbitrary Revisions”, and the file version menu in the navigation bar) get indicators for revisions that have annotations (such as commit tags or special status as branch head revisions). Further details are available via hover tooltips.<\/p>\n<\/blockquote>\n\n

This is an improvement, but most of my revisions aren’t tagged, so all I have to go on are the date and the commit hash. The comparison commands are great if I want to quickly go back a few versions or if I know the desired date. I wish BBEdit had another column or pane to show the commit message. Otherwise, there’s a multi-step process of opening the revision history, finding the desired hash, and then looking for it in the other window. At that point it feels easier to switch to Tower and locate the file there so I can use its history browser.<\/p>\n\n

\n

AI worksheets support streamed responses, which will shorten the\ntime before responses from the service start to appear in the\nworksheet. If wrapping is turned on (as it is by default),\nstreamed responses will appear in chunks (corresponding to an\nunwrapped response line) rather than a word or two at a time.<\/p>\n

Added an “Other…” item to the popup menu for model selection\nin the AI Worksheet preferences, as well as in the worksheet\npopover. This makes an API request to the service (if supported)\nrequesting a list of the available models, and then provides a\nsearchable list.<\/p>\n<\/blockquote>\n\n

Streaming is a huge improvement, as some of the models take a while to produce a large amount of output. Instead of it looking like nothing is happening, you can start reading the response right away. The Other…<\/strong> command is much more important than it sounds because the pre-defined models that show up in the pop-up menu may not be the ones you want. I recommend checking the full list now and then and updating your default. In some cases you may want a model that’s not even listed there. For example, chat-latest<\/code> is the current ChatGPT Web model, and it auto-updates to use newer models as they become available, but it doesn’t appear in the list returned by the API. Also, beware of old worksheets that are still set to use an old model.<\/p>\n\n

My other tip is that the AI APIs BBEdit uses seem to default to more concise responses than you would get on the Web. There’s no setting to change this, but you can prompt it within the chat to be more verbose.<\/p>\n\n

\n

The codeless language module internals have been extensively reworked to improve performance, and to correct longstanding issues. With these changes, individual patterns (string, comment, keyword, etc) can be tested and developed using the Pattern Playground if desired, and used in a language module with some assurance that they’ll behave consistently (which was by no means guaranteed before).<\/p>\n

[…]<\/p>\n

Made significant performance improvements to SFTP protocol operations, including file transfers. Most operations will be visibly faster, in some cases an order of magnitude or more can be expected (limited by network throughput to the server).<\/p>\n<\/blockquote>\n\n

There’s a whole section of the release notes on performance improvements, but I think these are the two most important ones. I’ve been using BBEdit’s FTP support since the 90s. It’s always been convenient, but at some point I switched to mostly using Edit in BBEdit<\/strong> from Transmit because it felt faster. With BBEdit 16, the SFTP operations and browser feel so<\/em> much faster, due to using Dispatch I\/O and bulk communication with the helper XPC service. It’s usually quick enough that it doesn’t bother interrupting the flow with a progress sheet, so it feels pretty much like working with local files. Since getting back to working this way, I’ve rediscovered the benefits of having BBEdit manage the SFTP connection: remote files show up as recents so I can quickly go back to them, and I can leave a log file open and reload it.<\/p>\n\n

I continue to use BBEdit every day, for all manner of coding and non-coding tasks. It continues to be rock solid, and Bare Bones continues to do a good job adding useful new features while also maintaining and optimizing the old ones.<\/p>\n\n

BBEdit is still $60—or $4\/month or $50\/year (up from $40\/year) in the Mac App Store<\/a>—with upgrades<\/a> still at $30. Of course, many of the features also work in free mode<\/a>.<\/p>\n\n

See also:<\/p>\n