Ohh, BBEdit. I've long since moved on from the Mac platform, but I still have really fond memories of it and wish more text editors could match it (SublimeText is pretty good too).
I remember when BBEdit came out. It was revolutionary at the time. It was a fun challenge to find "large" files to test it on, and for a while nobody was sure how it did the magic it did.
It shipped with a really clean UI and it gave me my introduction to regular expressions. Its "light" theme is still so good that I occasionally try to clone it into environments (unsuccessfully).
When Mac development shifted from the THINK ecosystem over towards Metrowerks, CodeWarrior's IDE was such a pig that you'd figure out how to do the editing in BBEdit and the debugging and compiling in MWCW.
BBEdit also shipped with a rare (again, at the time) ability to open and juggle loooooots of windows, and with a little bit of Applescript we'd try to open an entire directory of files just to see if we could make it faceplant. It almost never did.
I have a huge amount of respect for Rich and having stuck to doing one thing and one thing well for so long. (Well, kinda. TextWrangler was okay, and MailSmith was pretty good but got sold.)
My memory of CodeWarrior is a bit different. It didn't seem like a pig, but BBEdit just worked better for editing files. BBEdit had better search/replace, shortcuts for navigating text, everything was just better in BBEdit.
FTA: "We’ve always had the utmost respect for the user. Every internal decision about look and function answers the questions 'What does the customer need?' and 'How can we help them be more productive?' (Not 'How can we give them what they’re asking for?' because that isn’t the right question to answer.)"
I experienced this first hand when asking Rich to restore the "hard wrap to window width" feature in TextWrangler[1] (it had also been removed from BBEdit).
He quickly and kindly replied that while "We don't have any plans to restore the 'Window Width' option for hard wrapping" I could "describe how this would be useful to you" for him to "give it some thought".
I simply downgraded to restore the desired functionality, as I did not want to waste the author's time arguing over the utility of a feature that had been included for ages.
Since then, I've purchased BBEdit licenses, but use other editors when I need to hard wrap text to window width.
Heh. I just looked up an exchange I had with Bare Bones support from 2001 (!) about the hard-wrap-as-you-type feature. This was an early BBE feature that was removed when they added soft wrapping.
I tried to argue for this feature but was politely refused. The argument was: "It is not so much that the code can not co-exist as that the combination of user experiences causes confusion. The two states (hard wrap while typing) and soft wrapping have the same visual result and would tend to cause considerable confusion. Because of this we removed the first when we added the second."
It's 22 years later and the feature has not been restored. I wonder how many times its been refused.
If it’s export to pdf I’d think simply being on Mac solves that assuming it has print functionality. Is the issue the print functionality in MacOS can’t handle files as big as BBEdit can making using that sometimes impossible?
Or maybe it is actually a lack of print functionality and you’re remembering export to pdf cause it came up in that conversation?
I would test myself but I don’t have the app installed right now.
Was this intended to be a positive anecdote? It doesn’t sound like one - how is removing a feature users care about and refusing to add it back any evidence of “utmost respect for the user”?
I read this as a positive. Practicing what you preach. Rich asked for a further introduction into the needs behind the users request. The user decided not to pursue that further. Perhaps the feature could have been re-introduced if the client had a very clear user story. We won't know. Is it fair to ask users for stories when you introduce UI/UX regressions. That's debatable. But Rick showed real interest consistent with expectations.
> Since then, I've purchased BBEdit licenses, but use other editors when I need to hard wrap text to window width.
BBEdit is incredibly scriptable and extensible. You could have written a short script in AppleScript, Perl, Ruby, Python, etc. to perform this task without leaving BBEdit.
According to Script Debugger, hardly the massive powerhouse that may end humanity like GPT-4, it's the "bounds" property of a window, specifically the 3rd element.
I'm somehat worried about the incidental harm caused by people relying on GPT's word chain hallucinations as facts for something critical.
Most laypersons don't understand that GPT is not a factual search engine. I'm increasingly seeing people who should know better also forget this now and then.
the problem is that the quality of data on the web is such you can't really trust what you get from google either, so you need to go back to the pre-google days of using specialized search engines, or accept that some of what you get back is likely polluted and you don't have the resources to verify everything.
The web is a swamp of hot garbage, in large part thanks to Google SEO incentives.
If Google hadn't poisoned the well, and if searching pulled up good content instead of ads designed to look like search results, and search results that link to web pages that take 5 screenfuls to convey one sentence of information, they wouldn't be looking down the barrel at an existential threat.
Turns out that the strategy of saying something false in order to get the right answer works even better when the false statement comes from an LLM. I guess I'll keep that in mind.
> only use BBEdit once or twice a month (usually for multi-file search and replace via regex).
BBEdit’s regular expression support is jaw-dropping. Combined with how quickly it can update north of 10,000 files has kept me using BBedit for over 25 (!) years.
I can’t believe this has to be said here of all places. GPT-4 is not a search engine of factual knowledge. You can not assume anything it says is true and not just a made up grouping of words that look nice together.
True, strange that everyone understands this about people, but hold computers to be an authority.
Computers had this level of respect even when they spat answers onto a teletype and were called electronic brains whose thinking was represented by spinning tape reels flashing lights and an occasional beep.
Hah. VIM has had both soft and hard wrapping since forever and they're visually distinguished by the line numbers and line continuation marks in the gutter. I find it extremely useful, as I don't want to write overlong lines for commits &c, but do want to soft-wrap existing long lines where they are found.
> (Not 'How can we give them what they’re asking for?' because that isn’t the right question to answer.)
We say some very similar variant of this where I currently work, and also at previous places. Personally, I've never been able to understand this in any other way than:
a.) our users are idiots, we developers know much better then those poor souls
b.) our users are idiots, adding a feature without taking away a marginally-similar feature would be so confusing for them, poor souls
And I think it's why BBEdit gets this historical puff piece that reads like an in-flight magazine piece congratulating Madonna on still being able to dance at this late stage of her career.
I used BBEdit 1.0, and probably every version after that -- including the OpenDoc component[1] version!! -- but I finally stopped paying for it after version 13, after realizing I only ever used it for dealing with my Japanese bank's legacy-encoding CSV files. (Which I still do, to be fair, but the free version works for this.)
I don't think BBEdit has maintained legitimate relevance, in terms of writing most kinds of code, or even more complex text-processing workflows (for which it is better-suited relative to coding), and IMHO that's basically because of this attitude of "our users are dumb! we must protect them, poor little lambs!"
For instance, despite having had rectangular selection quite early, when it was rare (20 years ago? memories get hazy...), I don't think they ever made the jump to Sublime-style multiple cursors and discontiguous selections/insertion-points (later made 9 quintillion times more popular by VS Code) -- arguably the most significant advance in text editors since the introduction of multiple windows.
Likewise language servers and basically everything since 2013 or so.
I might be wrong, though; I look at text editors from the writer-of-software perspective, mainly. TFA references people using BBEdit to write English, and as that endeavor has gotten more complicated ("just write it in Markdown" somebody once said to my father, and he threw a spiny squash at their head) maybe BBEdit's niche has shifted. I don't think it is relevant today as a source code editor, but maybe as a blog post editor, or applied statistics prompt editor, etc?
> We've always had the utmost respect for the user. Every internal decision about look and function answers the auestions "What does the customer need?" and "How can we help them be more productive?" (Not "How can we give them what they're asking for?" because that isn't the right question to answer.)
That’s hard to do and I would guess that their ability to distinguish between what users ask for and what they need is a big part of the software’s longevity.
> That’s hard to do and I would guess that their ability to distinguish between what users ask for and what they need is a big part of the software’s longevity.
True, but it's also necessary. As Henry Ford (supposedly) famously said "If I had asked people what they wanted, they would have said faster horses."
I've always thought this anecdote about Henry Ford is misleading, if not utterly false. In most cases giving people what you think is best for them and not what they ask for, results in a completely failure. Only a small percentage of cases actually leads to a groundbreaking new technology. But our memory is biased: we only tell success stories and forget the failures...
If anything the anecdote should be about identifying what users actually want. They didn't really want a faster horse, they wanted a way to get around faster. They couldn't envision a different way so they embedded the "faster horse" solution in their response. However Henry Ford correctly identifies the core problem and gave them that.
The Henry Ford quote is based on the premise that most people lack the technical knowledge and problem understanding needed to develop visionary solutions, and would just try to give you what they think is best for you (a faster horse, a cleaner car, a fancy new dependency, etc).
The Henry Ford quote is both dumb and extremely misapplied. It basically tells you that a successful, category-defining mass market product, does not look like what you'd get if you imagined asking a bunch of friends a quick question and took their imagined ad-hoc answers at face value.
I say imagined, because any actual horse owner would tell Ford they don't want a faster horse - they want a horse that's stronger, eats less, and shits less, as those were the real constraints of the horse platform[0].
(There's also a healthy dose of condescension in assuming "most people lack the (...) problem understanding". This may be true when you're thinking up a new class of a mass-market product. It's definitely not true when you're playing with some specialized product people already use productively.)
Also note the context here is pushing a new product category on the mass market. It's not about making an incremental improvement to existing product category, nor making an incremental improvement to existing product - two scenarios which most companies operate in, and in which this quote is most misapplied. In those scenarios, your users - again, note, not prospective clients, but existing users - most likely know the problem space way better than you do. They may have problems communicating the details of their feedback, so you need to actually try and understand what they're saying. Talk to them. Have them show you how they work.
--
[0] - Strength translates to work/carrying capacity, eating less would give exponential savings on logistics to large horse operators, such as militaries, and as for the last part... suffice it to say that in Ford's times, horse manure was a bigger and more immediate health problem than air pollution is today.
I’ve had non-technical users, who used the application daily, ask me to implement a large form where every input was a radio button.
When I suggested using a more appropriate mix of drop-downs, checkboxes and radio buttons they readily accepted.
It turns out they thought radio buttons would be easier for me to implement. They aren’t stupid people, they just don’t have any idea of how things work outside their domain.
It's also a puzzling anecdote, since Ford did not invent the motor car, it already existed when he started making his cars. And his early cars were slower than horses or horse-and-carriages of the time.
That's usually the (supposed) quote that is brought up when somebody questions this "don't give the user what they want, figure out what they need" notion.
And it sounds great, and makes you laugh the first time you hear it (but yawn the next 9,999 times...)
But think it through: how many customers really would have actually said that?
Wow, you guessed correctly! It was indeed, four guys, out of all the customers Ford had. If he had asked them, which he said he didn't.
But how many of those four would have really said that if they didn't happen to be drunk?
Wow, correct again! Indeed, zero.
So in fact this whole pithy little quote -- regardless of whether he said it or not -- is just shorthand for HAW HAW USERS DUM AS SHIT BRO LMAO
BareBones has had several good programs to go along with BBEdit.
Yojimbo is a kind of catch-all database where you can cram stuff and organize it. Kind of like a Pinterest for all kinds of things, not just images. With the family pack, everybody can have access to the same lump-o-stuff.
Way back in the day, they had Mailsmith, which was, more or less, a POP mail client with BBEdit crammed in. (This was back when pretty much all email was text and not HTML.) If you used email a lot, and needed to do clever things with it, it was fantastic. It never made the jump to IMAP AFAIK, so it kind of died out. I really liked it, but in today's world where a lot of email doesn't come multipart MIME, just HTML, it would be less useful.
But BBEdit is just great. Much like emacs, once you get immersed into the ecosystem, you find leaving it difficult. You end up with a collection of snippets and widgets and scripts and bits and bobs that become your workflow. And you can script all of it as well. It continues to chug along with ridiculously large files, even back when you might work on files bigger than the amount of RAM in your machine.
I'll remain a Mac user for as long as BBEdit works on it. While I can use other editors, if I have the choice I'll work in BBEdit.
I recently emailed a guy that, if you sent him a text-only email (as I normally do), it would go into his spam folder or get vanished. I had to turn on HTML email to send something to him.
They used some version of Outlook. Don't know if it was in-house or the Microsoft hosted service or what. Plus whatever gimcrack spam filters they might use in house. I've seen some nonsense on the Internet, but this was a first for me. Absolutely bonkers.
I really wish they or someone would turn Yojimbo into a scientific papers PDF organizer/reader, or at least have some support for this. Papers was good but got bloated and the standalone is not supported anymore
I like Yojimbo on Mac, but for the life of me I can't figure out why their iPad app is read only still. I understood it when it first came out, but they added all kinds of features on the Mac version, such as iCloud sync, but the iPad app still only syncs via local network only, and it can't edit anything, and doesn't take advantage of things like web views.
If you're looking for something like Yojimbo with near feature parity on macOS and iPadOS, take a look at DEVONThink Pro. I use it with a ScanSnap and ExactScan as my digital filing cabinet.
I haven't used BBEdit regularly since I discovered Vim (and now Neovim) 10+ years ago, allowing my license to lapse. But I couldn't resist the 30th anniversary sale to purchase the latest version for $30.
The UI hasn't changed much, which is both good and not so good.
Neovim will continue to be my daily driver but I'm glad to support a small, local (to where I live) developer who's been making great Mac software for a long time.
> BBEdit is like an insurance policy just in case…
I'm curious to understand how proprietary software can act as an insurance policy against open source software. I can understand how the reverse would be true.
I think he means insurance in the sense that if he wants to use it (for whatever reason) it's there.
But BBEdit, while proprietary software, doesn't make proprietary files. They're just text files. So if BareBones went insane and turned BBEdit into a front-end for TikTok, your files will still just be text files. Even BBEdit's "Project" file is just a text file.
It think OP means insurance in that they know how to use it well and can "fall back" to it if their current choice fails to meet their needs. I do not think they meant insurance as in failsafe/archival purposes/the company shutting down.
BBEdit was my first text editor ~15 years ago! Back when I was really obsessive over the small stuff because I wanted to be like the cool kids. I then got into Text Wrangler, vim, emacs, nvim, etc. over the years. I was really into customizing my environment.
Now I just use IntelliJ and VSCode. Don't really have to think about it, plugin system has grown enormously, and I rarely need to spend time futzing with my configs because excellent themes are free and plentiful. Progress!
I use vim and don't futz around with my config. I feel like this is a perpetual myth that vim or emacs requires endless tinkering. I maybe touch it once a year, and I still have:
- LSP support - code actions, hover, gotos, linting.
- Fuzzy finding with previews (with syntax highlighting thanks to bat)
- Integrated Git
- Integrated Terminal
- Integrated Debugger
It's a real shame that IntelliJ and VSCode users scare beginners off from trying out all the amazing editors like Vim, Barebones, Nova, etc. with this FUD that they won't get anything done. I've seen people swap between editors like SOs in high school and I've been able to consistently stick with Vim my entire career, so maybe the FOTM editor crowd are really not seeing the gains in productivity they believe they are getting by always picking the "out of the box" editor.
Just doing a basic google search shows me at least 4 plugins that interface with chat GPT. I personally don't use them because my workplace doesn't allow feeding our code to another companies backend.
I'm not a huge fan of app stores in general, but I have to give Apple credit for these articles they do. Never too long, high quality and interesting ones like this come along semi-regularly especially the design-centric ones. I've actually found a few good apps through these over the years, partly because of design showcases that looked cool and partly because the developer seemed like a nice person and I wanted to check their app out.
I'm sure Apple have the utmost respect for their users, and the internal decisions that led to this design choice answered the questions "what does the customer need?" and "how can we help them be more productive?"
"Read" is a particularly unlucky verb for this because its past participle and imperative form are written the same way. Most other English verbs wouldn't have this particular ambiguity.
"Never eaten a Carolina Reaper pepper, but I'm looking forward to my first time."
"Never eat a Carolina Reaper pepper; you'll regret it."
Wiktionary has a few dozen irregular verbs that could produce an ambiguity like this one:
Say what you want about BBEdit no longer being useful in the modern era, but whenever I have to work with a multi-megabyte file that my IDE chokes on, BBEdit can open it no problem.
The killer feature of Sublime for me is cross platform. I am stuck in Windows at work, and I have a Mac at home. I don’t need to have to think where I am each time I edit text.
I’m a Mac user, but for my job I have a company Windows laptop. It used to come with UE and I absolutely loved it. I work with large XML files (think 500 MB) a lot and UE would open/format/xpath/regex/etc. them with 0 issue.
Then upper management forgot they employed engineers and did not renew the license.
Now I’m stuck with VS Code which chokes when I open a 20 MB file.
On the Windows side there were a bunch of editors that had similar features or had already solved the issues BBEdit solved for Mac users. It was popular, but not ubiquitous the way BBEdit was.
I haven’t kept up with it but UE is still the most functional editor I’ve used. I’ve dabbled in Sublime, BBEdit, VIM and others but UE had some tricks none other have matched.
BBEdit was an essential component of not having to deal with the terrible editor & even worse runtime stability of CodeWarrior for a spell in a past life of mine.
Thank you, BBEdit.
Also, you’re low-key responsible for my lifelong unrealized quest to give my Linux workstation sane keyboard shortcuts.
Oh heck, you've just dredged up some absolutely horrific repressed memories of that pile of junk. It was impressive how unstable it was.
It's funny too, these days I'm in embedded development again, and it's a markedly different experience to those days, though still amusingly unstable at times too.
Interesting. Do you remember which version (or approximate year) you're referring to?
I've recently been writing my first real app for Mac OS 9, using C++ (MacZoop framework) and Codewarrior Pro 5 on a G4. There's some features I miss from my modern developer environment (decent version control!), but other than that it's been a thoroughly enjoyable experience. Certainly I've had no stability issues at all with the IDE.
2004-2005! Couldn't tell you the version though I'm afraid. I had nothing but issues with it, man it frustrated me haha. It's possible my memory has made the experience worse than it actually was however
I've no reason to doubt your experience at all, I'm really just idly curious. Was that on Windows though? 2004-2005 I think it was all but gone from the Mac, and people had moved to Project Builder (later Xcode), but maybe you were still working on some older project.
AFAIK the current CodeWarrior is based on Eclipse, if they're still updating it.
I think it was, yes, and specifically for some embedded toolchain that required it. It would regularly lock up, crash, and lose my work. Though it’s quite possible the toolchain was at least partially the problem, and I wish I could remember which one it was. I might go digging through my old backups, I’m curious myself now
After Freescale bought Metrowerks (1996? '98?), there were versions of CodeWarrior made for many of Freescale's embedded chips, which were obviously very common.
Again, in spite of my current experience I don't doubt for a second that you had a lot of issues. Software was just a lot worse back then, and having now dipped my toes in the frameworks and languages used in the circa 2000 period, I'm not really surprised why. There's 0 references to automated testing in any of the programming books or documentation I've looked at, and as far as I can tell absolutely no support for it. Version control is extremely rudimentary. I didn't programme professionally until early last decade, and some of what I can infer to be have been normal is just baffling for me.
Back in the good ol’ days of no memory protection on the Mac and the fun of trying to figure out if it was you or your dev environment that just unrecoverably hosed the system state.
Really? I though CodeWarrior for PalmOS was a champ compared to Visual C++ for embedded platforms. Lets start with a fully functional and bug free compiler with standard library and all features working.
BBEdit was my first editor when I was learning to program for the web on my Power PC bubble mac. It's crazy to think it was considered old when I was using it and that it's still around now!
They've been doing them a while. There are pieces on the devs behind Things, as well as interviews with Craig Hockenberry (The Icon Factory), Gus Mueller (Flying Meat) and Ken Case (Omni Group). I'm sure I've also seen one with Cabel Sasser of Panic too.
<3 BBEdit - it's become a bit outdated in terms of UI/UX and features, but it's still my daily driver for anything plain text. Its Regex search & replace still rules over a lot of other GUI editors. I've pretty much upgraded to each new version since my first boxed copy about 25 years ago. Back then BBEdit was quite the powerhouse for HTML development, and it helped me finish a lot of projects.
A few years ago I noticed that all the other editors seemed to have online enthusiasm. Having used bbedit for decades and having exchanged email as tech support many, many times, I asked Rich if bbedit was a thriving or if it was just hanging on. He assured me that thriving was the better characterization.
I would interpret that to say for-profit is applicable though, having had projects that lasted a long time (not thirty years!), I can say that sticking with it that long is always, also, a labor of love.
And I failed to mention the one aspect where bbedit exceeds every editor I have ever tried (a few years ago, I actually did a half year where I tried everything): Search and Replace.
The Search and Replace feature of bbedit is absolutely the best ever. When I am forced to use another editor, I am appalled by contrast. Since I use this 1000 times a day, I will never change. bbedit forever!
I'm reading this thread and am, again, surprised by the fact of people changing editors willy nilly. I have customized my bbedit experience endlessly. I have text filters, dynamic snippets, script elements, 'text factory's and a zillion project files (I often have two or three for one project so I can open the configuration or the UI or the back end separately.
I can't imagine choosing to give up those decades of custom features I've built into my workflow. Nor can I figure out how I would work the practicalities. I would say that it is literally impossible for me to change editors at this point.
And, I consider this all to be a tribute to bbedit's flexibility, speed, and solid, hard core reliability. I love that program. If they offered a paid release every year, I would ante up happily.
I'm reading this thread and am, again, surprised by the fact of people changing editors willy nilly.
Based on reading discussions on HN over the last decade or so, it seems that a lot of people on HN don't choose editors because it's the best tool for the job, but because of the same factors that affect the fashion world: Flash, style, color, trend, posturing, and peer pressure.
I've banged out code on everything from a green-screen Wyse terminal to Panic's Nova, and there's nothing better for reducing productivity than changing and reconfiguring your tools in the middle of a project.
John Gruber of daringfireball fame and co-creator of Markdown worked there for awhile. His chapter on regex in the BBEdit manual is widely regarded as the best out there.
I have fond memories of writing HTML with it, and various other things, but I almost never use it anymore. The regex playground is awesome but I never think to use it, even though I still keep a licensed copy around.
I use Neovim a lot more and then perhaps VSCode, as I live in a world with a lot more going on and a lot more integration with other tools, a very different world to that which makes BBEdit a go-to app. Also, I don’t think it’s that impressive with large files. Still, gotta respect a hit.
> FTA: "We’ve always had the utmost respect for the user. Every internal decision about look and function answers the questions 'What does the customer need?' and 'How can we help them be more productive?' (Not 'How can we give them what they’re asking for?' because that isn’t the right question to answer.)"
That's not utmost respect, but condescension when you think you always know /can figure out better than the user
I think you're reading this the wrong way, there's (literally!) decades of scientific literature about it, and it's not a problem of being condescending.
Could you me just a tad more specific instead of sciencing around? For example, I've read your article and its argument is simply not relevant
> Good UX research, however, does not ask people what they want. That’s because people find it difficult to put themselves in imaginary situations, especially in cases where they need to picture a future with products and technology that do not currently exist.
But this is a text editor, gazillions of those exist, with various UI paradigms and features, it simply makes no sense to claim that all users, even those very experienced in alternative apps (so nothing imaginary about that), don't know better than BBEdit's small design team, thus it's ok to ignore their explicit asks because you know "what they really need"
Like in the example cited above with removing hard wrapping, the quoted argument "The two states (hard wrap while typing) and soft wrapping have the same visual result and would tend to cause considerable confusion. " is patently false as there exist editors with very clear separation of the two (and those being confused can always disable either). But then if you think you know better, you keep being "utmost-respectfully" wrong for years
I cannot give you a specific example in this case, because I don’t know the feature, use case and problem… which is kinda the issue at hand. But the claim that “users are familiar with other apps, we should give them the exactly same features if they ask for it” is not very sound: first of all, not all users will be familiar with other editors. Those familiar might have had a very hard time learning them at first. And, in general, it’s good to ask “why do you want that? Show me how you use it and why you think it’s important, and we can test multiple design alternatives until we found something that works for you”, instead of “let me add feature X from editor Y” (both because there would be no innovation, but also no reason to change editors).
For the article, the relevant part was: “ In general, a researcher will first ask a customer to walk through how they currently solve a particular problem. As part of this investigation, they will probe at the user’s pain points and existing workarounds”. What is the hard wrapping used for? Maybe there’s a better way of solving the same problem to begin with, and hard wrapping is just a band-aid instead of the proper solution to the underlying goal?
By the way, UX research doesn’t claim that designers cannot get anything wrong or that users can never get anything’s right - that’s a silly simplification of course. But I don’t think the the BBEdit author was trying to promote such an absolutist view.
Developers who do what the users tell them to build the worst stuff. Imagine what a state your plumbing would be if you told your plumber where to put the pipes. The correct line of questioning is not "what do you want?" but "what is the problem you are having?".
I never used it, but I certainly had to support web devs who did, and who needed me to open up FTP to the website so they could integrated-upload their markup.
There were a bunch of "does it do PASV" conversations. Because, FTP is sufficiently old-school (like telnet) that it believed in archaisms of how to open a distinct data port to a command port, and it made firewalls very unhappy unless you could use "passive mode" which was firewall friendly.
We wrote our own CMS using DAV (in Apache), and I wrote a push-publish engine which was on the "inside" master and would push out via rsync a checked out state respecting symlinks. It was kind-of like "stow" but for the networked web from a repo.
the BBEdit users weren't happy, they had their own idea of a CVS tree using "tortoiseCVS", we had many fine arguments about how to do it (most of the web was theirs but a small portion was not, and was in fact Apache::Perl rendered which was in a code repo, and combining multiple sources of authority over web state is always a very confusing place to be)
I think you may be mixing up some memories? tortoiseCVS was (is?) a Windows product and has nothing to do with BBEdit (which only runs on MacOS). I don't recall BBEdit ever imposing restrictions on CVS repositories (and I used it extensively with those for a decade, though only since about 1999).
I am also confused by what point you are trying to make regarding FTP? "Web devs wanted to upload files via FTP" sounds pretty normal for a website 15-20 years ago? Of course it also unclear when your story takes place...
From memory, our webdevs used a mixture of mac and windows. They had a private CVS repo, Some of them were using Tortoise and editing on windows, and others used BBEdit. (I thought there was a cvs client GUI on Mac too but I guess not)
BBEdit integrated some publish/checkin features as I understood it but you had to have enough CVS fu to manage some of it "outside" the tool.
(and, what I read suggests CVS was something you had to actually install on the MacOS of that day, from some repo or another, probably whatever proceeded XCode. the developer tool bundle?)
It was entirely normal to do FTP 15-20 years ago. The problem was, that FTP was bifurcated into two forms. "traditional" FTP with two channels one of which was a back call to the client and PASV mode which was the one which worked through firewalls better, where the server set up a path for the client to call into.
Maybe you never had these issues. I know a lot of people at the time (like me) fought with FTP services and connecting clients who couldn't enable PASV, or didn't know how to turn it on, or whose firewall admin wasn't up to speed with enabling things to make FTP work.
I forgot to note that the permission set needed to make XHTML and like functions work meant setting the execute bit on some uploaded content, sometimes. It wasn't adequate to just mark a file as .xhtml always, for things like SSI to work let alone CGI scripts. You can do that in FTP if you can issue the commands, or you can ask FTP to preserve state for you, but again from hazy memory CVS didn't always like chmod state of files checking things in and out.
My story takes place around 1999/2002-3. If I mis remember forgive me. I had already been working 17 years online by the late 90s, and this BBEdit stuff is now 20 years ago for me. I forget more than I remember.
Most of my daily work is done with BBEdit and has been for over 25 years now.
They saved my butt last year when my old Mac Mini melted down. I had another old Mac Mini a friend gave me and when I contacted BBEdit they gave me a copy to get me back up and running without any hesitation even though I couldn't give them my serial number.
By the time I switched to Mac it was already MacOS X Jaguar and it had vi which I was used to. I didn’t buy my first BBEdit license until 2 years ago (!!) thanks to a blog post I read. It’s a great editor. I’ve always liked macOS because it felt like the Linux I use at work, but BBEdit is a great reason to not run vim fullscreen.
I've been a developer for three decades and have done a few things that I'd like to think are worthy of some merit - but my credit as one of the 'unindicted co-conspirators' in BBEdit is absolutely one of the things I'm most proud of!
I pretty much stopped using bbedit when moving over to osx from system9. It had the ability to run emacs (there were some emacs ports for pre osx mac, but they all annoyed me in one way or another) and that was a nice return 'home' for me. I remember having to work on a project on a windows machine in the early aughts that drove me nut until someone handed me notepad++ and called it 'bbedit for windows'.
That all said, nice of apple to write a little puff piece about it and it's author. BBedit was a workhorse for many and continues to be for many. It's one of the few very successful mac apps that apple didn't just steal (like watson).
BBEdit is my weapon of choice for reading massive log dumps and database dumps for support at $DAYJOB. It does not seem to ever choke no matter how many hundreds of megabytes if text I need to plow through.
That and random snippets of text that live as
unsaved documents for days to months.
BBEdit is a big misfit for me and how I use editors. It’s great at transforming text and zillion of other features but I get my work done in VSCode or PyCharm. My true preference was Atom. RIP
Even with this all, I still install BBEdit on every device I can.
BBEdit was known for that in the past, but it's a weak point these days. It definitely has an upper limit on filesizes and will "choke" on large files (probably only slightly larger than the log files you're using it for).
Other apps are much better at large files. The APFS filesystem has a maximum file size of 8 Exabytes and plenty of other text editors can handle file sizes that large without any issues.
I used BBEdit for about 10 years. I liked being able to create macros that included multiple grep search/replaces. I think I remember being able to files items from the sidebar straight into a SFTP app instead of opening them in a separate finder window...but that might be a false memory. It was extremely hard for me to leave it behind for SublimeText, but I did...and eventually moved on to VSCodium from there.
To this day I still use BBEdit even though most of my daily meat-and-potatoes text editing and development is done in neovim. For some things it's just really nice features and UI, in particular:
- the multi-file search and replace,
- the diff tool,
- shell worksheets
and so much else.
BBEdit has always been a fundamentally fast and reliable text multi-tool and I've used it since 1994 when I first started poking around HTML and learning Perl.
Dang, I love it. The feature list looks good enough to back the claim. It almost sounds like an editor for Linux. And I'm also curious if there are any Linux alternatives?
What data structures were used to represent the content in-memory and edits? Was it some sort of an immutable set of chunks organized into a tree, similar to Word?
I recently bout BBedit on their 30th birthday event.
BBEdit / TextMate has the Mac feel that I enjoy editing long-form text in (recently, a lot of latex manuscripts); meanwhile, vscode is where I write code. I don't know what contributes to this difference exactly, but they occupy a different part of the market as of now.
This is great editorial coverage by the App Store team. I’ve long thought Apple to be discarding a great opportunity with marginal curation and storytelling regarding great apps, niche or otherwise, so this is encouraging to see. I hope we see more like this BBEdit story.
Back in the day it may have been UltraEdit, but these days I'm sure there's something else. I've been using Notepad++ because it's FOSS, but it is probably too quirky to be an analogue
Programmer's Notepad is amazing, its been my goto in Windows for well over a decade at this point. Has everything I need without any bloat, also work fine on large files (I often do regex-searches on huge log files with it).
I still run it on vintage Macs. Pretty sure it was the first programmer's editor I used on Macintosh. A lot of the Macs in college (iMac G5/10.4 era) had TextMate, which I got pretty used to, but still ran BBEdit at home.
Free version of TextWrangler was the sweet spot, for me. BBEdit is more than I need for day-to-day and seems comparatively slow. Not an "upgrade" I wanted.
I started using BBedit around 1995. If I hadn't left Apple/MacOS for Linux about 15 years ago, I would definitely still be a (gladly paying) BBedit user!
Same story here basically, I loved BBEdit back in the pre-OS X era, especially after I installed Macsbug and learned how to dig my essays out of memory and write them to disk if anything crashed while I was writing...
I was on a Mac constantly from 1989-2009, I'd became a bit of a free software zealot and moved from an iBook to a ThinkPad. It's funny, because a lot of people were making the opposite move, and as I understand it the early 2010's are looked at as a bit of a by-gone golden age for Apple now. Can I ask why you chose to move?
Yeah, TextMate was great. I think it was the very intuitive way in which you could quickly extend it.
Find yourself typing this thing over and over? Just create a snippet, the interface is just very few clicks away.
Need a bit more power? Turn it into a command, and use whatever scripting language you’re comfortable with.
Want to change the color scheme? Here is a nice declarative way to select precisely the syntax elements you want.
(I think part of this was that they had a bunch of short videos on their site showing you how to do this, and then a well-written documentation to accompany it for the details.)
Sadly, with TextMate 2.0, the interface for these things got quite a bit clunkier, and then I left. (I also discovered my preference for modal editing.)
I still use TextMate. I don’t know whether development has slowed or stopped, but I haven’t had any issue recently. I find it less clunky and nicer than Sublime Text, which is my second choice and my escape route the day TextMate dies. It’d be a pain to convert all those bundles, though. TextMate’s support for esoteric language grammars is second to none and last time I checked some of mine depended on features not implemented in Sublime Text.
I remember when BBEdit came out. It was revolutionary at the time. It was a fun challenge to find "large" files to test it on, and for a while nobody was sure how it did the magic it did.
It shipped with a really clean UI and it gave me my introduction to regular expressions. Its "light" theme is still so good that I occasionally try to clone it into environments (unsuccessfully).
When Mac development shifted from the THINK ecosystem over towards Metrowerks, CodeWarrior's IDE was such a pig that you'd figure out how to do the editing in BBEdit and the debugging and compiling in MWCW.
BBEdit also shipped with a rare (again, at the time) ability to open and juggle loooooots of windows, and with a little bit of Applescript we'd try to open an entire directory of files just to see if we could make it faceplant. It almost never did.
I have a huge amount of respect for Rich and having stuck to doing one thing and one thing well for so long. (Well, kinda. TextWrangler was okay, and MailSmith was pretty good but got sold.)