BBEdit 14 | Hacker News Reader

BBEdit 14

barebones.com

287 pointschmaynard159 comments

> We know that many of our customers create a lot of untitled documents for quick note-taking, and rely on BBEdit's legendary stability and robust crash recovery to protect their work. We've added a new "Notes" feature in BBEdit 14...

Ooh, guilty as charged. I see an "Untitled text 931". It's a list of hostnames. "Untitled text 107" is a Beef & Broccoli recipe.

This is the main reason BBEdit has been with me for a decade. I have NEVER lost an unsaved document during that whole time. You quit BBEdit or restart or crash macOS but they're always there when you're back in. Insanely robust.

Is there anything like it on Linux?

IMO every program must work like this. I hate so much those "do you want to save this file" when I close a program. Don't ask me, just save it somewhere and restore when I open the program next time. It's trivial to implement and much easier to use.

> It's trivial to implement and much easier to use.

...unless you opened the document from a network share or removable media. Or serialization takes a long time. Or the storage device is slow. Or you don't have write permission in the file's original location and have to pull a potentially large file from somewhere to persist changes to some local position. Or the local storage device is full.

A "always save" mechanism would be best on a system that supported copy-on-write, network-aware links, and automatic file versioning to make writes super cheap. On actual real world systems that currently exist these mechanisms don't really exist or aren't universal so "always save" is fraught with difficult to handle edge cases.

You don't have to write in the same directory as the original file (and you definitely don't want to overwrite the original file). Original vi (and nvi) keeps the working copy below /var/tmp. If you can't write there, you have bigger problems.

(just be consistent from which host you modify a file from ;-}

Writing to /tmp is great if your file is loaded entirely in memory. Not all programs do that for a variety of reasons. Like I said, it's the tons of edge cases that make "constantly save" problematic and far from a trivial feature.

/tmp often is a RAM based file system. Not the best destination for data intended to be permanently saved. (n)vi is primitive enough to insist in copying the whole file (usually not a problem with files meant to be edited interactively), but nothing stops a more sophisticated program to store only changes (transactions) and consolidate on request. Most software, certainly all interactively used, ought to be "crash-only" software [1].

[1] https://www.usenix.org/conference/hotos-ix/crash-only-softwa...

It was even better working on a system that versioned files automatically so programs didn't need to re-implement these sorts of wheels continually.

Dave Cutler was right.

Only a minority of programs need that functionality. Databases and everything which implements transactions or version control itself, certainly don't. Neither all the temporary files, e.g. a compiler creates. If version control of your configuration files is external to the host (e.g. if some configuration management system like puppy, chef, etc. is used) then it's get in the way as well.

Dave Cutler was wearing his marketing hat when he claimed that such functionality belongs in the file system code. It would be nice, if it were in a library all interested applications could easily link to though.

> Databases and everything which implements transactions or version control itself, certainly don't.

Why should programs implement these themselves? It should be part of the OS.

I don't think you can get Oracle, IBM, etc. to agree on how a database ought to be implemented. It clearly depends on the use case as well. More fundamentally one can argue, that what can be implemented in userspace ought to be implemented in userspace (for security and maintenance reasons alone), rather than the kernel. And what good does a db do in a compute node?

I essentially have versions for all my files because of Apple’s “Time Machine” backup system. There’s the external drive at my desk and there’s also the cache of recent changes it maintains in free space on the local drive.

Both of these have saved my ass in the past. I don’t care if it’s actually part of the file system, but it sure as hell belongs somewhere in the OS IMHO.

There have been a lot of scenarios where blowing away everything since the last save and reverting to known-good via the Open command has saved my ass.

The solution I think works best is to flash/blink the Save button when a file has changed. And ask them to save when they leave. Then, the user is more easily reminded to save when they feel it is most appropriate to do so, but is not compelled into saving and can revert to a previous version if they like.

Sublime Text has always performed similarly for me

Yep, ST’s unsaved default workspace is completely reliable for me—it’s survived power outages on my desktop (while I was actively typing) without a hitch.

This Sublime feature has worked for me except for a single time... During one of the interim, 3.x upgrades I lost all of the open but not saved notes files.

This is the reason I haven't upgraded to Sublime 4 yet.

I had that issue when upgrading from 3.x->4 -- I was so cocky from years of ST's insane consistency that it honestly didn't even occur to me that my unsaved documents might be lost.

I wasn't even mad; just a little surprised

I didn't have this issue when upgrading to 4, just on an interim 3.x update. Maybe the OS made a difference. I had that issue on a Mac.

Visual Studio Code has yet to lose workspaces, untitled documents or unsaved changes for me. What is more likely to happen for me is accidentally running Git commands while I had buffers in VSCode with unsaved changes.

I ran into this issue [0] when updating VSCode which caused it to delete the contents of my unsaved/untitled document.

[0]https://github.com/Microsoft/vscode/issues/69972

OK. So relying on unsaved buffers long-term might still be less safe than in BBEdit, assuming Microsoft hasn’t made improvements that prevent this sort of scenario from happening again.

However, it definitely wasn’t out of sheer negligence, as they do have tests that try to ensure unsaved data will make it from the last stable version to the current version at all times. Without doing any serious research, all I can say is that it is unfortunate, but if you don’t keep unsaved buffers and changes for long periods of time it is at least fairly safe...

https://github.com/microsoft/vscode/blob/main/test/smoke/src...

I think this is the sort of thing where trust is lost after just once, never to be regained. Sort of like if someone lies to you, you can never trust them again, because they've done it once.

I think think because software is so new, and the choices are still so slim, many are much more lenient than they would be with a human.

However, as it matures, and there are more choices, we can regain the freedom to exclude any software from our lives after it misbehaves just once, and still have plenty of choices.

Personally, I've given up on Mac, and before that iOS, and before that Windows, and I'm so much happier, because I have invested that time into choices which do not let me down.

I've done the same with dishonest services, too. No more LinkedIn, their emails forever trashbinned.

But like people, the circumstances matter. VSCode dropping the ball once has to be weighed against why it happened, what they were doing to prevent it from happening, etc. If it happened more, you’d lose trust in that feature, but it’s hard to leave something over a single feature that’s buggy. I can’t think of another text editor I’d rather be using.

For me, I don’t rely on this feature because I normally save anything that I want to keep for longer than a day. My PoV is that anything that isn’t backed up is already lost, so if it really matters, I need more than just hoping my software and hardware won’t fail. Dropping unreliable software is still always an improvement, but if I dropped every piece of software that ever failed me, I would have no software.

vim: https://github.com/chrisbra/vim-autosave

Any sufficiently large thread about text editors contains a pitch for an ad hoc, bug-ridden, unnecessary plugin that's overkill for achieving some effect which is already possible just using a build of Vim mainline.

:help swap-file

Sublime Text.

Vim (cross-platform) supports ability to restore from the "swap" file (by default, AFAIK, but that may very well be a special configuration decision by my distro).

If your system crashes or you lose power while editing foo.src, it will leave the swap file behind, which is eagerly written to disk while editing and only removed when the process shuts down gracefully. When you bring your system back up and try to edit foo.src again, you'll get a message "Swap file ".foo.src.swp" already exists!" and prompt you for whether you'd like to recover it or not. Any unsaved changes you made will be reconstructed from swap, rendering the file in the same state it was before.

Vim also supports a closely related concept "sessions", which you can force with ":mks" and restore with the "-S" flag. This will re-open whatever files you had open at the time, in the same layout, and more.

What would be interesting to see are "super swap files" that are passively created (like ordinary swap files, requiring no intervention) but do everything that session files do and more, like preserving movements, markers, undo history try, etc. -- essentially getting you back to exactly what you had at the time of the interruption.

What is the performance cost of this sort of thing? I suppose it depends on how often it autosaves, but if it's too infrequent you end up loosing work anyway, and you could imagine it being a problem for files above a certain size.

Probably 25 years ago now, I've trained myself to habitually use "vim -n" for very large files for which recovery isn't required.

The swap file stores edits rather than the whole file. I guess this could be laggy if you were doing global substitutions on a massive log file, say, but I've never had an issue. Vim was written for much slower computers.

What's the performance like? Real fuckin' fast. Ever used Vim? I don't and never have used hardware that would be considered especially beefy.

Jetbrain's products have the concept of scratch files, of which I've made thousands over the years.

> Is there anything like it on Linux?

VSCode. I use it on Mac and Linux and make heavy use of this feature.

Vscode was one of those “Microsoft made an editor on electron? Why would anyone use that” to “WSL2 and vscode is way better than mac” debates I have now. Am I the baddie? Btw I would just use Linux if my friggin corporate overloads supported it. I could BYOD but all my devices have some sort of pirated movie or a doom2 wad from the internet that I don’t feel like talking to HR about.

Emacs. Emacs will autosave every 300 keystrokes or 30 seconds of idle time. You can also configure it because well its Emacs. Has saved my butt on numerous occasions.

It will not reload your session by default but you can do that if you want.

+1 for Emacs autosave. Note that an autosave file is not the original file you were working on but a copy saved at the interval you specify. The original file is left untouched until you explicitly save it.

In case Emacs aborts for some reason, at restart Emacs will alert you that the newer copy exists and ask if you want to use the copy instead, which you usually (but not always) do.

If you want Emacs to automatically save the original file after a configurable interval, use auto-save-visited-mode.

Isn’t that a native feature in MacOS? I never “lost saves” since years.

Notepad++ on Windows has been the standard bearer for this functionality for quite a long time.

Second this. Other products have it as well but Notepad++ has worked very reliably for me.

Lol! Same here.

I want them to have some paid lite mode, that I could purchase and support them. Given my use case I feel like $40 is a bit much but I’d gladly pay $20 for a note taking app.

Didn't they have TextWrangler for this?

AFAIK, TextWrangler has been discontinued in favor of BBEdit.

On another note, I just found out that the Notes feature is indeed Premium one. Hmmm.

Yeah - it's worth pointing out that BBEdit itself, can partly be used for free, indefinitely. You're allowed access to a subset of features (which is very similar to what TextWrangler offered), without needing to pay.

I think they reached a point where, even if the codebase had originally been forked from BBEdit, it was just plain dangerous to have a second codebase floating around. I think after they had done the same work (bugfixes, feature additions) twice for quite a while, they just decided "yeah, this was a mistake", and pulled the plug.

Ugh, I do this with Notepad++ too, and I know it's terrible. But it's just so.... automatic. I tell myself that nothing in there is truly critical, but I've also had a few instances of being pretty pleased to be able to "find in all open documents" and recover a bit history of what I was doing, or URLs for some research, or whatever.

I use Notepad++ like this too.

But I try to use its split pane feature to keep all my scratch txt files out of the way of whatever project files I need open.

I'm utterly unrestrained with it because I don't even use NP++ as a text editor for anything else— my actual projects are in VSCode or just terminal vim instances.

>scratch txt files

We started using rider at work and I already have made like 20 scratch files in under a week. It may become a problem soon.

I‘m reluctant to change over from TextWrangler to BBedit due to fear of loosing those unsaved „Untitled text 461“ documents.

Does anyone now if BBedit restores TextWrangler‘s untitled docs?

I'm fairly certain that half of my 200+ 'untitled text XXX' docs started in TextWrangler, so yes.

I suddenly feel less alone in the world.

This is such a great addition to BBEdit's impressive legacy

That's what I've been doing with Notepad++ for years and years. It doesn't even prompt you to save when you exit, it just restores your previous open file panes, including ones you didn't save.

(not sure if I had to change a setting for this)

You don't have to change a setting, that's the default behaviour :D

same here! i was going up to hundreds of new files for my notes. very comfortable!

I see a lot of "oh, but this is what a lot of editors do" comments. But BBEdit 14's Notes feature is not "we save untitled files"; it's a little more like the Notes app, or like a more limited version of Ulysses's sheets. It's explicitly about saving documents that you don't bother to give titles to.

Also, a neat trick BBEdit has had since version 13, I think: it can actually recover untitled documents even after you close them and say "no, don't save."

uh, what? that does not sound like a feature to me - I expect that when I close a document without saving it is gone for good. Is there a way to turn that off?

Absolutely. (...checking preferences to make sure I am not lying) Yes! Absolutely. :) You can turn the feature off completely, and if it's enabled, you can set a time limit for "rescued" items before they're completely discarded, e.g., yo could set it so you have a day to rescue them, then they get truly deleted.

Thank you!

Thanks to using BBEdit for a decade now, I get bitterly disappointed whenever I re-open an application and it doesn't restore the windows and state it had when it closed. I've tried switching to both Emacs and Vim, but no amount of configuration nor third-party plugins could get them to work like this effectively. BBEdit works exactly how I want it to work out of the box, and I commend it for that.

I don't know about Vim, but Emacs will do this easily with `persp-mode`. To skip a bit of customization work, get doom-emacs and enable the `workspaces` module, which will save sessions for you by default.

Tim Pope has a plugin for that: https://github.com/tpope/vim-obsession

That's true so often, you could probably write a bot for that response

And half the time it will reference a plugin made by tpope

Be careful what you wish for. I use one application which does not check whether the computer goes from 2 external monitors to the built-in laptop monitor. When I reopen the app on the laptop without the external monitors, all of its windows are drawn completely off the screen. The only way I know how to fix this is to reattach the external monitors, move the windows to the built-in screen, then close the app again.

If you're in Windows, and the off-screen window has focus: Alt-Space -> M -> Any arrow key, and move the mouse.

Shouldn't your window manager give you a way to handle this?

Shouldn't your window manager just handle this for you, by moving the windows to the builtin display when the external monitor is detached, and moving them back again when it's reattached? (Like my Mac has been doing for I don't know how long?)

I'm not sure what this comment is supposed to add to the discussion. It's the same as those comments that just say "This", except it does it with 40x the number of words, no?

> I don't know how long?

Since 1987

> I've tried switching to both Emacs and Vim

It is an endless source of irritation that the fans of these editors are so relentless in their refusal to shut up and stop denigrating alternatives that people are left feeling that they must use them, regardless of whether they're a good fit or not.

> I've tried switching to both Emacs and Vim, but no amount of configuration nor third-party plugins could get them to work like this effectively.

Emacs can easily do this.

Holy cow, this the same BBEdit I used as a teenager with System 7.

Incredible. Makes me nostalgic for resource forks & resedit.

Yup. I've been using it for at least that long.

I've tried "trendier" editors, from time to time, but always end up going back to BBEdit.

yap. not to forget TextWrangler

They rolled it in to BBEdit a couple of releases ago. TextWrangler is now effectively ‘BBEdit free mode’

You can set BBEdits icon to be TextWrangler, for those who are nostalgic and don’t know.

Yes, same here! I got my first Mac with 7.5.3. It was a Performa 5200CD. Good times :)

BBEdit was preinstalled on campus Macs when I was an engineering undergrad... in the mid-late 90s. I have made an entire software career, 25 years, since then, and still Rich Siegel soldiers on. Amazing.

Instabuy. BBEdit is the one app that has been on every Mac I've ever owned, since the 1990s in fact. No other Mac app I know has existed that long. It has always been rock solid and reasonably priced. I happily buy upgrades when they come out every few years. Thank you, Bare Bones, for staying the course!

LSP is a game changer simultaneously raising our expectations for a code editor and lowering the bar for editors to get there.

LSP was such an awesome idea. It's amazing to me that this wasn't a thing before Microsoft introduced it in VS Code. It's incredibly useful for every editor.

> It's amazing to me that this wasn't a thing before Microsoft introduced it in VS Code.

For what it's worth, the static analysis infrastructure we built for Dart was designed this way and, I think, existed slightly before LSP. We used it to provide a nice Dart IDE experience in the Dart Editor (a custom build of Eclipse), IntelliJ, Emacs, Vim, etc. without having to reimplement everything multiple times.

Cool stuff. I think there were a few similar efforts going on. For example, LSP was based on the protocol developed for OmniSharp, which was an open source .NET-specific implementation started in like 2013 by a Vim fanatic.

Interesting! Is there a source for that? I remember OmniSharp. It was a blessing when I could start to use vim when I had to use .NET a few years ago. I had no idea that's what LSP grew out of.

A source for LSP growing out of OmniSharp? Interestingly I'm not finding much. This isn't a totally accurate history but it's close enough: https://blog.logrocket.com/how-to-use-the-language-server-pr...

The original project was at https://github.com/nosami/Omnisharp (see https://news.ycombinator.com/item?id=6006954). But over time it was split into several repos.

The history article above says that OmniSharp started out on Roslyn, but actually it originally used NRefactory. The old server is here: https://github.com/OmniSharp/omnisharp-server

EDIT: Oh, just found https://github.com/microsoft/language-server-protocol/wiki/P... . This cites OmniSharp and also the TypeScript language server.

That's worth something, but having a standard protocol is worth so much more. If your architecture had become the de-facto standard for this stuff, I can assure you that I'd be praising it instead.

Standard in what sense? Surely Dart has its specific requirements like any other language. I'm not convinced it's possible to standardize such functionality without limiting yourself to a subset of what you might want to have implemented.

Standard in the sense that most languages and most editors have adopted it: https://microsoft.github.io/language-server-protocol/impleme...

In that case I'm not sure that it's "worth so much more". As I said, you end up with lowest common denominators, not with increased developer comfort. For example, in case of Common Lisp, I very strongly doubt that LSP supports such things as interactive resumable conditions, CLOS/MOP object model for cross-referencing, or image state and session handling. At least it didn't a few years ago when I looked at it. But sure, if you're not very demanding, something like LSP might be enough for you.

Does that work in BBEdit?

You gotta love how on their website they have the "Made with BBEdit" icon in the footer.

https://www.barebones.com/images/BuiltWithBBEdit.jpg

Brings back memories of when all websites did this and included Netscape/IE/etc icon banners.

I miss multiple cursor on non-contiguous text with BBEdit. I feel like this feature should be standard. I was blown by that feature when I saw it first on Sublime text.

This is the feature that drives me to Sublime. It’s easily half of what I use it for.

> I was blown by that feature

Is the feature Premium? Or only available in free mode? Just wondering...

It is available out of box. I was referring to "Quick Add Next". https://www.sublimetext.com/docs/multiple_selection_with_the...

It supports rectangular selection via option drag, including zero width rectangles, which seems to cover all of the multiple cursor use cases I need. I do realize some other editors implement more multiple cursor features, so I grant that some folks may miss those.

For those curious, I wrote a review the other day called "BBEdit 14, and why you should care":

https://micro.coyotetracks.org/2021/07/19/bbedit-and-why.htm...

(And yes, I know many of you may have valid reasons not to care, but I was aiming mostly at Mac users who think "oh, I remember BBEdit" but haven't used it in a decade or more.)

Saw this editor names several times before, but never used it. Out of curiosity, how does it compare to Sublime Text?

With the caveat that I've relatively little experience with ST, they're in the same ballpark and probably roughly equivalent. BBEdit is probably dated in some ways and mac-only, but _possibly_ even more stable and quicker than Sublime Text.

coding can be slightly more comfortabale with ST depending on its plugins, for instance Julia is a treat given that VS Code can't be silenced to ST-standards [code-sensing-wise : eg ZenMode under Win may only work full-screen; attempting to switch off all code-sensing won't work, always something 'popping-in' when moving abouts in the editor -- that's how M$ is : either overdoing it and not getting the most basic things right or getting part of it right w/out providing options users desperately ask for : they decide what's best pratise for users and that >feel< is exactly not the sort of feel both, ST and BBEdit transpire]

besides, BBEdit can be incredibly fast when it comes to larger files, sorting and in particular regex-search

[never ever employed any Mac w/out ST, BBEdit, FileBuddy and DiskWarrior; HexEdit and few other free utilities, and one could get work done quite efficiently]

I like the completions of Sublime text a lot better for most tasks. ST’s packages are also really powerful and BBEDit isn’t extensible in the same ways (though it is through AppleScript and a host of other things).

After the 30-day “trial” is up, the features in its free version are more than worth keeping it installed for. I keep an active license for it in addition to Sublime Text because it’s my preferred tool for complicated RegEx things and multi-file search.

After the 30-day trial expires, BBEdit becomes what used to be a separate application from the same developers called TextWrangler. TextWrangler was my first code editor because my dad had it installed on the family iMac for its sophisticated grep capabilities.

That’s what they’ve replaced TextWrangler with, but if you look at the feature comparison page, the free tier seems to do so much more than TextWrangler did that it feels less accurate to call it that — I was never a TextWrangler user, though, so I’m not qualified to say from experience.

I used to use Applescripts with BBEdit but it's got unix script support too.

For example, I write Ruby scripts that act on the file, either to change to the text or just to run commands, and snippets are available to fill out text with a jumping cursor to replacement points. I'm not sure what Sublime Text packages offer that BBEdit can't as it's been a while since I used ST/Textmate regularly.

I haven't used BBEdit in over a decade, so my sense of its capabilities are surely out of date. I can't compare features, but I can tell an interesting story.

Sublime Text is arguably a spiritual descendant of BBEdit. Sublime Text (starting with version 2) was heavily inspired by TextMate. In fact it used TextMate file formats for colorschemes and snippets, making it relatively easy for TextMate users to migrate to ST2. That was a major reason for ST2's rise to mass popularity — TextMate was not receiving updates and was MacOS only, and in comes ST2 offering a very similar editing experience, but with cross-platform support and frequent updates.

TextMate, in turn, was heavily inspired by BBEdit. BBEdit at the time was, as its name suggests, fairly bare-bones. It had auto-indent and syntax highlighting and very sophisticated grep capabilities, but not much else in terms of programming support. For a long time, it was THE code editor for mac users who wanted a graphical interface but not an IDE. TextMate rose to popularity by mostly mimicking BBEdit, but offering additional programming features like snippets and shell-script based plugins and more sophisticated syntax highlighting (enabling e.g. correctly highlighting CSS and JS embedded in an HTML file).

With BBEdit 14 now apparently supporting LSP, it looks like it has incorporated a lot more programming support features. It might at this point be a more-or-less mac-native take on Sublime Text.

> TextMate, in turn, was heavily inspired by BBEdit.

This assertion is surprising. They're not all alike in any way that any two Mac-native text editors wouldn't be. Sublime is markedly different only because it dispenses with Mac-native UI conventions (which IHMO makes it unpleasant to use on macOS).

> BBEdit at the time was, as its name suggests, fairly bare-bones. It had auto-indent and syntax highlighting and very sophisticated grep capabilities, but not much else in terms of programming support. For a long time, it was THE code editor for mac users who wanted a graphical interface but not an IDE. TextMate rose to popularity by mostly mimicking BBEdit, but offering additional programming features like snippets and shell-script based plugins and more sophisticated syntax highlighting (enabling e.g. correctly highlighting CSS and JS embedded in an HTML file).

This seems not quite accurate.

My recollection is that BBEdit was just another Mac plaintext editor app -- solid, but stodgy -- until the Web arrived, and someone built a suite of HTML editing commands for it. That's when it took off. It was the plaintext editor everyone used for HTML until TextMate came along.

My experience with BBEdit was circa 2008, just as I was first learning to code. It's much older than that, yes.

Idk, maybe TextMate wasn't terribly similar to BBEdit, but at the time the landscape of non-IDE graphical editors was fairly limited. I'm only aware of BBEdit and TextMate on Mac, Notepad++ on Windows, and Gedit and Kate on Linux (there were also the vaguely graphical ports of emacs and vim on all platforms, but I won't count those). So I see TextMate as, at the very least, being part of a genre of text editor defined by BBEdit.

One important differences is that Sublime Text is available on the principal dev platforms, BBEdit is Mac-only.

... is there another principal dev platform besides MacOS?

LSP is game-changing. I had made a bunch of clippings to work with for TeX and Python, and this obviates the need for most of those :)

Can someone here explain to me the appeal of BBEdit? I’ve tried using it several times but it never clicked with me. (I’m an Emacs user.)

My story is rather dated and admittedly only one data point, but when I was in my early teens (early 2000s), WYSIWYG editors like Frontpage and Dreamweaver were the tools I used to self-learn the basics of web dev. The issue though was that those editors were rather bloated and ran very poorly on the machine my mother had bought me, so it became increasingly favourable to seek something lighter weight and non-WYSIWYG as I learnt more about the languages of the web and grew more competent. stumbled upon BBEdit and used it to a) grow my knowledge of the languages and; b) be able to build things in a more productive manner without the computer grinding to a halt. I think perhaps learning to code through WYSIWYG and then migrating to text editors is a common pathway?

Anecdata: I didn't learn web stuff via WYSIWIG (but I did VB6 that way, a bit). My first web-app was built with ASP in notepad and smashing that refresh button. I still don't like the graphic, I'm coding it (like a caveman?)

This was exactly my path to loving BBEdit since it let me be a productive PHP dev (insert joke here) on the 5+ year old PowerMac 7300 I was able to afford at the time with my own money as a young teenager. I remember the HTML capabilities they added around version 5/6 being a really huge deal for a lot of people: http://www.atpm.com/6.10/bbedit.shtml

I don't use a Mac daily any more, but I still can't use anything except ProFont in my editors after growing up spending so many hours staring at bitmap Monaco 9 in BBEdit: https://tobiasjung.name/profont/

I've been using BBEdit since v4.0. One thing that sticks out for me was, way back in System 7 days, I opened up a huge (for the time) CSV text file to do some search/replace. I don't remember the size, but it was larger than available RAM on the machine, so maybe 20MB. It opened, and I was able to work on it.

Recently I had to open a 1GB text file in BBEdit to also do a search/replace. (Not something I could use the command line easily for, because I had to make executive decisions as to keep or replace what I found.) Worked flawlessly.

The application is ridiculously solid. Like emacs, it's very customizable. I have several wonko scripts written in PHP that I can use to munge data, but you can also use Applescript, or Perl, or whatever. Code snippets are great.

But the real appeal is, again, similar to emacs: once you get into the workflow and set your editor up the way you like, including keyboard shortcuts, layout, etc., you can become insanely productive. It becomes a personalized environment to such an extent that the thought of moving out is terrifying.

(Years ago, Bare Bones had a mail client called Mailsmith. It BBEdit-ized your mail client. I loved it, but email moved on and they didn't keep it up. I still miss it.)

Are your scripts available somewhere? I would love to take a look at those. Can other languages be used instead of PHP?

I keep a (badly in need of an update!) repo of BBEdit stuff[1], it's mainly Ruby. I guess BBEdit runs the script in a similar way to a shell in that it's the shebang line that matters most. If your system supports it, then I believe BBEdit will support it. Downloading it for a wee look and having the manual open[2] while you try is well worth it.

[1] https://github.com/yb66/BBEdit-stuff/

[2] https://www.barebones.com/support/bbedit/manual.html

Sorry for being late, but thank you so much for these.

In my own experience, it's a solid but outdatedly old-school code editor, but it shines spectacularly in text processing.

I always tend to use other editors as my daily driver (TextMate, Atom, VSCode, whatever the new flavor is), but I always keep BBEDit around and updated for this reason. Eventually I am going to need to open an enormous CSV or logfile and do things to it and BBEdit is there for me. It happily opens the thing where other apps scream and choke and die, and it has great text processing tools to do things with that data.

Another thing that's not my reason for liking it but is very real is it's incredible Macness. Unsurprisingly given its 30+ year history on the platform, it's an extremely well behaved Mac application that adheres very cleanly to Mac user expectations of behavior. Doesn't matter that much to me personally, but you'll find a lot of the old-school "fondly reminiscing about Mac SE/30s" types really appreciate that it just feels more like a Mac application than probably even a lot of the built in MacOS applications these days.

I use it as my main visual plain text editor, but use vi on the CLI and JetBrains stuff for coding. The use cases I like it for:

- copy/paste ANYTHING, every tried to copy something from the browser and paste it to the CLI and nothing happens? Anytime I have difficulty pasting text, I paste into BBEdit first and then copy it again to paste into its destination. BBEdit eats any kind of text, it's amazing.

- Large files, I've found nothing is faster for opening and editing large file >1G

- Note taking - Has a few advantages over other options (Bear, Notes, Evernote) here that I don't miss the rich text features of those others. 1) No automatic autocorrect for spelling but the manual autocorrect is still there which means I can write tech jargon without getting frustrated 2) Autosave without having to think of a title or folder 3) Immediate start up time, no waiting for the doc to load even if I have >100 open docs

- batch text processing - if I need to do find/replace I tend to go with BBEdit over CLI, I can build up the regex pattern and have undo capability. Use it a lot for making SQL statements from lists of ids and the like.

A few other points I didn't see anyone mention:

Extensive Applescript support. I'm going to go out on a limb here and assume most HN readers are not fans, and probably those who know any of it hate it. But, BBEdit has great documentation and an extremely solid and comprehensive implementation. It's one of the only Mac apps I truly feel I can do anything at all with in AS.

Shell worksheets. Something of a Mac-only tool, I think. Emacs users won't be impressed, but this feature isn't common on other Mac editors, and I think both camps can agree "why the hell NOT?". Having your shell environment be your text editor is great!

It’s in a very precise midpoint between Notepad and an IDE that preciously few other text editors stand in.

It's the editor equivalent of Word 5.1 for the Mac; the thing that people think of as being "just right".

I switched to BBEdit after 10 years of being an emacs user. The main reason was I could actually use all the features of BBEdit, versus emacs where I could never remember the commands. BBEdit also had commands for most of the text transformations where I would have to break out elisp or go looking for someone else who had solved the problem. Eventually features like code folding and editing files over SSH locked me in for good.

The main issue over the years was that BBEdit's support as a code editor was never as good as emacs. Syntax coloring was anemic and it couldn't indent lines etc. I'll have to try out the LSP support because that might address that issue.

I use BBEdit and love the editor (esp. love the new LSP support), but have hated the name and the icon for a long time. I have all these beautiful macOS icons, and then there's BBedit with it's weird acronym name and encyclopedia looking icon. Maybe it's time for a rebranding for the next generation!

But seriously, BBEdit IMO beats out VSCode for speed and stability by a mile if you're a macOS user. And you're supporting a much smaller company than Microsoft.

The icon is definitely updated in 14.

It is, but it is still really ugly and feels very out of place on a Mac.

edit: typo

> It is, but it is stilly really ugly and feels very out of place on a Mac.

How? I just download it, an the icon looks totally fine to me.

Also, BBEdit is really old. Having it change its name to suit modern fashions is about as desirable as having Emacs do the same.

I agree, I'm not suggesting a name change at all. That would be bad. And obviously the idea of the icon being ugly is completely objective, but I just don't like it. Bad colors. Bad shapes. Idk. It looks old, probably because it is. But plenty of old companies have modernized their logos in a pleasant way.

> I agree, I'm not suggesting a name change at all.

I was kinda responding to an ancestor comment with that statement.

> Bad colors. Bad shapes. Idk. It looks old, probably because it is. But plenty of old companies have modernized their logos in a pleasant way.

Modernization is often a regression. Looking at the icons in my apps folder, there are way too many seemingly standard-size circles differentiated by a little color or a less-prominent icon, and most of the rest are a standard-size squares with similar characteristics. It's like if the alphabet was all O's, but with different colors and small diacritics. IMHO, "modern" UIs tend far too much towards indistinguishably in order to achieve a "unified" look, which looks good in a quick demo but is detrimental to daily use.

However, the ultimate mistake is Apple's, for creating a text-free dock that makes the icons do too much work. And of course, Apple's mistakes must be copied by everyone else, because they're so good at marketing (I'm looking at you, Microsoft).

you can make it look like TextWrangler too if that helps

https://macosicons.com/

Unfortunately it doesn’t stick if there’s an update but it solves the problem temporarily.

Replacicon is $3 well spent if you want custom icons to stick between updates

https://replacicon.app/

>>But seriously, BBEdit IMO beats out VSCode for speed and stability by a mile if you're a macOS user

I've been using BBEdit since the first release and I would never trade it for VSCode. They are totally different beasts to me. VSCode has been ridiculously stable for me and, as far as I can recall, has never crashed or lost a single line of source code. VSCode's speed has never been an issue, as it is ALWAYS open all the time, lol. I restart to update it and that is that.

On the other hand, BBEdit is always open as well, performing totally different tasks. These days, I use it mainly as a persistent note taker and text munger. I will definitely be looking to test the new "Notes Window" functionality!

Both great tools, open 24x7 on my dev mac.

I made a revised icon that imho fits in better with the Big Sur's look and works at Dock sizes:

https://twitter.com/jmfd/status/1417595485653635073

Great, solid, reliable editor. Great documentation.

And don't sleep on the diff tool bbdiff. For text diffing it's pretty fucking good.

This is prominent among many reasons why I’ve kept BBEdit installed on all my Macs since the mid-‘90s, even after most of my development workflow shifted to zsh-nvim-tmux

BBEdit has the best regular expression engine second only maybe to Perl.

BBEdit is the bees knees!

It also seems to open much larger files than other editors will handle without breaking a sweat. Not my daily driver but I keep it for those files.

I'm surprised no one has mentioned the release notes yet. I've always thought that Bare Bones' release notes read like a love letter to their customers. I love the little bits of humor and personal touches in them too.

I should probably switch back to BBEdit for my daily editor. It's the editor I reach for when I hit one of the cases that chokes my other editors.

I guess it would already be my daily editor except for some gaps.

LSP probably closes one main gap for me. Now that I'm looking I see some other gaps are also closed.

(Though a remaining big gap is that I have to do a lot of work on Windows and some on Linux, and I'd rather not have two different daily editors.)

I switched to Nova about 6 months ago - great editor and development seems supercharged compared to BBEdit.

I keep meaning to pick up Nova out of love for Panic, but every time I've tried a new editor[0] I end up switching back to BBEdit.

0 - https://news.ycombinator.com/item?id=25135058#25162222

Same, the UI of Nova is too flashy for my taste, I love the simplicity of BBEdit, and the perceived performance difference. I have been using Sublime and BBEdit intermittently , I will give it another try now that they support LSP.

As much as I love Panic and their software, BBEdit's LSP support is considerably more solid and its text editing engine is just a lot more powerful. There are still some advantages Nova has and it's certainly prettier, but after about a year of using Nova -- I started with the betas! -- it still feels nerfed compared to both BBEdit and Visual Studio Code (which I'd argue is its more natural competitor).

Wonder if it can be made to work as nicely as TextMate for ruby/rails work.

I really wish it supported keyboard rebinding. I really wish this. I would happily pay for it, over and over again, but the tab key behaviour when editing structured text is just ... wrong.

There's a whole preference pane called "Menus & Shortcuts" which lets you set new keyboard bindings for virtually everything.

I'm not sure what behavior you're looking for with the tab key in structured text, but if you're complaining that by default it will replace selected text with a tab character rather than indenting the whole thing, you could always go to the Keyboard preference pane and check the box by "Allow Tab key to indent text blocks"...

I have never once — in a career as a professional programmer that is coming up on 30 years — needed to insert a literal tab character in a document I’m writing. Not once. I’ll check out the bindings control panel, but in the past (as of maybe v12) it has not been possible to always force the tab key to indent the current line.

[shrug emoji] I have indeed needed to insert literal tab characters in documents, for a variety of reasons, from editing tab-separated value documents and other data files to programming where -- as shocking as it may seem -- we indented with tab characters rather than spaces. Also, of course, if "expand tabs" is on, the tab key inserts the appropriate number of spaces.

At any rate, I don't know when BBEdit may have added that preference. It's always, AFAIK, had "shift right" and "shift left" commands bound to Cmd-] and Cmd-[ respectively, which follows a pretty long, albeit informal, tradition of Macs apps using those for changing the indentation of existing text. (I get that it may seem awfully pedantic to separate "change indentation of existing text" from "change indent of text as you're typing," but if you've been using computers for 30 years, it's surprising you've never seen that before. The first time I selected text and typed tab and the indent changed, it actually wasn't what I wanted and I was pretty confused as to what the hell was going on, although of course I've gotten used to it since.)

Fair enough, and I'm not saying that BBEdit is wrong, per se, but it is close enough to useable for me (as a very long time Emacs user) that when there's something off, it strikes me as really off.

Curious, that's a pretty valuable domain name nowadays, right?

Ah BBEdit, the first editor that stole my heart!

I can't believe this thing still has legs.

how can one author say "I have spent more than a thousand productive hours using your product" ?

That's just half a year of full time use in a standard day job. An editor could additionally be used outside of work for taking notes or working on side projects.

I've probably used VS Code over 5000 hours in my life. (Halfway to becoming an expert!)

It's been around since 1992, even a very casual user could have easily racked up more than a thousand hours.

Me, I only have a few hundred hours, but they were some of the most formative hours of my career.

Reply on news.ycombinator.com