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.
"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:
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?"
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.
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.
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.
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!
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.
> 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...
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.
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.
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.
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.
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
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.
> 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.
Thank you for the tip. I'm in and out of several text editors during the day, but only use BBEdit once or twice a month (usually for multi-file search and replace via regex).
EDIT: According to GPT-4, "BBEdit's current scripting model doesn't provide a way to directly access the current window width, and this type of functionality is not typically available in most text editors' scripting APIs." If anyone knows a workaround, please share it here.
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.
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.
> 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'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.
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.
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.
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.
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?
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
176 comments
[ 2.8 ms ] story [ 182 ms ] threadSomewhat surprising, but props to Rich, that is some impressive work, above what I already thought was impressive work!
Then I read back my own words and invariably insert the 'I' as I realise it doesn't make sense.
"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:
https://en.wiktionary.org/wiki/Appendix:English_irregular_ve...
"Never miscast Magic Missile ..."
"Never shut a door on someone's finger ..."
"Never preset the thermostat to 90 °F before going on vacation..."
"Never put an irregular verb in a position where readers might interpret it ambiguously..."
("... but there's a first time for everything, I guess" / "... you won't be happy with the results")
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.
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.
AFAIK the current CodeWarrior is based on Eclipse, if they're still updating it.
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.
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!
- 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.
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 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.
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.
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
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.
[1] https://tinyapps.org/blog/201807150700_hard_wrap_window_widt...
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.
EDIT: According to GPT-4, "BBEdit's current scripting model doesn't provide a way to directly access the current window width, and this type of functionality is not typically available in most text editors' scripting APIs." If anyone knows a workaround, please share it here.
And, no, GPT is not a tool for factual verification, it creates probable chains of words that are likely to be found impressive by humans.
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.
And I'm looking forward the next quarter century.
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 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.
with gpt, you got nothing but the same convincing tone.
1. I want to change the highlight colour. It is too dim to recognize.
People in the forum asked: hey I don't want hidden settings. Can you make the highlight colour adjustable?
A: No. We won't do it. [1]
[1] : https://groups.google.com/g/bbedit/c/yz_StJa9HVA
2. I forgot if it is the print function or what, it just don't have despite in the year of 2022. Oh wait maybe that is the function "export to pdf".
People in the forum asked: Where can I do that thing?
A: We don't know either. Go find other editor if you want it.
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.
I'll admit I've never used said print functionality, so I can't rule out that it's missing something that some people consider important.
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.
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?
[1]: https://en.wikipedia.org/wiki/OpenDoc
It’s been more than 30 years, since BBEdit was released.
I use it a lot.
I never warmed to any of the alternatives.
It really takes an exceptional product to last eons and remain relevant.
BBEdit feels more like a product of love than oriented for-profit.
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.
From my experience SublimeText handles large files fine, but I never really tried to open multi-gigabyte size files.
I love SublimeText, it’s my favorite text editor and also multiplatform, so I have the same experience and tools on macOS, Windows & Linux.
Toggling between BBEdit and the CSS Zen Garden. Those were the days.
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.
Power to Rich Siegel.
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.
This is exactly what I meant.
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.
Discovering the command line tools was a very good day for me. I really like the built-in (two way) diff, and it’s my $EDITOR of choice on mac.
I've moved on to VSCode which has so many more features than BBEdit - it's not even close.
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.)
I never understood why there was so much love for BBEdit on Mac and so little love for UltraEdit on Windows.
They were both released around the same time, selling to the same audience just on different platforms.
This was also during a time where there was many options.
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.
It's still my editor of choice but it's a shame that they switched to a subscription model.
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’d always heard Rich’s name tossed around as a developer’s developers, but learned a lot more about him and his thinking from this article.
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 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...
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.