Ooh, guilty as charged. I see an "Untitled text 931". It's a list of hostnames. "Untitled text 107" is a Beef & Broccoli recipe.
Is there anything like it on Linux?
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.
...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.
(just be consistent from which host you modify a file from ;-}
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.
Dave Cutler was right.
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.
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.
Why should programs implement these themselves? It should be part of the OS.
I wasn't even mad; just a little surprised
It will not reload your session by default but you can do that if you want.
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.
VSCode. I use it on Mac and Linux and make heavy use of this feature.
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...
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.
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.
(not sure if I had to change a setting for this)
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.
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.
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."
Does anyone now if BBedit restores TextWrangler‘s untitled docs?
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.
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.
On another note, I just found out that the Notes feature is indeed Premium one. Hmmm.
Emacs can easily do this.
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.
Incredible. Makes me nostalgic for resource forks & resedit.
I've tried "trendier" editors, from time to time, but always end up going back to BBEdit.
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.
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.
Brings back memories of when all websites did this and included Netscape/IE/etc icon banners.
Is the feature Premium? Or only available in free mode? Just wondering...
(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.)
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.
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.
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.
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]
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.
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.
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.)
- 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.
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 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/
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!
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.
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.
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.
Unfortunately it doesn’t stick if there’s an update but it solves the problem temporarily.
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 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).
And don't sleep on the diff tool bbdiff. For text diffing it's pretty fucking good.
BBEdit is the bees knees!
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.)
0 - https://news.ycombinator.com/item?id=25135058#25162222
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"...
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.)
I've probably used VS Code over 5000 hours in my life. (Halfway to becoming an expert!)
Me, I only have a few hundred hours, but they were some of the most formative hours of my career.