While I'm using VSCode a lot more these days, I still like BBEdit a lot. It's a Mac-native programmer's text editor that manages to remain performant on large files.
I think part of the problem is that in order to make a good programmer's text editor, you need a large community of people who're able and willing to make good plugins for it, and any text editor with a userbase smaller than "half of all linux nerds" isn't going to have enough engineer hours put into all its per-language tooling. Visual Studio Code manages to attract enough developer attention to get people to work on compatible language servers and whatnot, but the granddaddy of all Mac text editors can't attract that much attention.
Plus, I get a _lot_ of mileage out of multiple cursors. Way more than I'd have expected ten years ago.
Not to nitpick an otherwise good argument, but the whole point behind LSP and language servers are that they are completely editor-agnostic.
A language server which enables great functionality in VSCode should be able to provide the same for other editors too.
Fair, I think what I meant is that Visual Studio Code has more IDE features than my emacs does (I know it's possible to have more but things seem less stable when I start using LSPs and such), but BBEdit has even fewer than emacs.
Maybe it’s for people like me that have never learned emacs.
This is a frustratingly hard assertion to defend, at least in very short form, but I've been a technical writer for years now, mostly working in Markdown, and I keep coming back to BBEdit. It's not one huge thing that it does better for me than other editors, it's a collection of little things: every editor has some kind of "open file by name via fuzzy searching" command, for instance, but BBEdit lets me open multiple matching files at once. (Yes, this turns out to be immensely useful for me.) It keeps a search and replace history and lets me save patterns with a meaningful name. Its "multi-file search" window isn't as fast as some other editors, but it's insanely targetable, and again, lets me save my criteria with names (i.e., "All but JSON"). The "Process Duplicate Lines" command lets me easily find "duplicates" defined with a match pattern in a 75,000-line JSON file (don't ask). I can build complex operations up and save them as a text factory. I occasionally do operations with its "Shell Worksheet" capability, sort of a weirdo hybrid between a built-in terminal and a persistent text file. (I also like that every project gets its own persistent shell worksheet and persistent "scratch file," which you can set to be any language type.)
I've tried a lot of other editors over the years, including VS Code, and either they don't have features that I use in my technical writing or they don't, at least to me, implement them as well. And as lame as some people undoubtedly think "it works like a Mac app" is as a feature, well, it's actually kind of refreshing to have a full-featured text editor that does that BBEdit works like a Mac app. It seems almost quaint to have an actual preference window come up in a text editor when you select "Preferences..." these days, but it turns out they're actually really good at, you know, setting preferences. (Modifying keyboard shortcuts is so much nicer in BBEdit than in any other editor I've used.)
Again, for coding, BBEdit has fallen behind the times; the structure is there for it to mostly keep up, but the ecosystem just isn't there and, barring a strange resurgence, probably never will be. Personally, I use MacVim for coding bigger projects now -- although I'll generally use BBEdit for short shell or dynamic scripts if it already happens to be open. But for managing huge honking websites with thousands of Markdown source files -- or even just dozens -- I just haven't found anything that beats BBEdit.
Yeah, I think perhaps this is what I'm missing. I'm a software engineer and at minimum in an editor I want syntax highlighting and code formatting (completion is a nicety but still largely a hassle outside of IDEs) and it's just not there for the languages I want to use.
I definitely appreciate the "works like a Mac app" angle, although in many ways it feels more like a Mac app from 25 years than I would like. It doesn't feel modern.
As for the modern aspect, I dunno. It doesn't look anything like Atom or VS Code, to be sure (let alone like MacVim or Emacs), but it's hard for me to look at the UI of BBEdit 13 and find anything that makes me go "oh, yeah, that widget right there looks really creaky." It doesn't have a tabbed interface for files, but I actually like its method of having a "currently open documents" list more than tabs. (When I've used VS Code, I configure it to do that, too!)
It's not so much this so much as it is not having the sort of Yosemite-esque translucency (I think vibrancy was the official name?) effect on sidebars and stuff which I've gotten extremely used to.
>One of the frustrating "what ifs" in the Mac editor world to me is: what if BBEdit's makers had added packages and, better yet, a package manager, to the editor a decade ago?
iirc it actually had/has a half-decent package format, but no manager or central repository for packages. The latter two are basically obligatory these days for a solid code editor, in my opinion.
>And code formatting is pretty much a dead end, even though I'm fairly sure it would be possible to set it up.
Really all that I want is a hook to run a shell script on save that runs the current buffer through mix format or rustfmt or whatever. Is that more feasible?
Yes, and yes, and yes. :)
> Really all that I want is a hook to run a shell script on save that runs the current buffer through mix format or rustfmt or whatever. Is that more feasible?
It would totally be possible, with the caveat that this is where you hit the one thing that does look really creaky: BBEdit's native scripting language is AppleScript. You can "attach" scripts to every single menu item, to several kinds of events (including both before and after saving a document), and the script could basically just be a wrapper around a shell script, but AppleScript will unavoidably rear its verbose yet inscrutable face.
I think studying old UX paradigms is super useful.
What Photoshop is to images, BBEdit is to text.
Yeah I get all these platitudes and stuff but I have used it and it doesn't seem more flexible than emacs here.