| ▲ | 8fingerlouie 4 days ago |
| ST is also all but dead. They switched to a subscription model (3 year licenses are still subscriptions), and since the release of ST4 in 2021, there has been exactly one release with new features (May 2025). All other releases have been bug fixes and "improvements". I get that developers need to make a living, but 4 years of fixing bugs in your products is probably not what I want to be paying for, at least not when that is the only thing I'm getting. Speaking of releases, they're also usually 6-12 months apart. I have used ST ever since the first version replaced TextMate for my use (TM2 spent something like a decade catching up to ST2), but I've since switched to Code and Zed (mostly Zed as of late, Code on windows until Zed is ready there). ST was great back when it was still an actively maintained product, but in recent years (ever since ST2) it has felt like it was mostly on the back burner and other editors have passed it in functionality. As for VC funding, it has done miracles for Code to have Microsoft sponsor it (and others). Code is currently the editor to beat for anything that doesn't involve opening large files. |
|
| ▲ | ben-schaaf 4 days ago | parent | next [-] |
| > They switched to a subscription model (3 year licenses are still subscriptions) Licenses are perpetual. It is not a subscription. Don't like the work we've done? You can continue to use that version of Sublime Text until the end of time. > there has been exactly one release with new features (May 2025) August 2024 we added kinetic scroll and xdg-activation support for Wayland; we also added the ability to configure image extensions and allow dynamically switching between the hex-editor and image view. November 2023 we added native font dialog support for switching fonts. August 2023 we added webp and proper support for running as administrator on all platforms. November 2022 we added syntax-based code folding and operating system recent file integration December 2021 we added GB18030 support. I'll stop there. Those are just the largest, most user facing new features, not any of the new settings, new APIs or improvements that I'd argue are new features. You can read the full changelogs here: https://www.sublimetext.com/download > Speaking of releases, they're also usually 6-12 months apart. We do stable releases infrequently, because they're stable. If you want more frequent releases you can switch to the development releases. You can see from the build number how many builds we've done of ST4 since the release: it's around 150. |
| |
| ▲ | 8fingerlouie 3 days ago | parent [-] | | > You can continue to use that version of Sublime Text until the end of time. Or until some change in the underlying OS makes it no longer able to run. Not saying that happens frequently, but it does happen. > I'll stop there. Those are just the largest, most user facing new features, not any of the new settings, new APIs or improvements that I'd argue are new features. New font pickers, settings dialogues and other "polish" is hardly what i'd call new features. I listed those as "improvements". I'm not trying to start a fight, and i respect the work that has been done, but VS Code releases more features in a month that ST has released in the entire ST4 lifecycle, as does Zed.
I understand the team is (a lot) smaller. My frustration is that when a new release comes out, it's mostly polish, and not fixing the real problems, such as lack of integration and plugins. You may choose to brush it off as just an old fart rambling on the internet, but i'm not alone with this opinion, and i have ST licenses dating back to the original version, and i have chosen not to renew my ST4 license. When you start losing the "religious" users, maybe it's time to reevaluate ? |
|
|
| ▲ | handsclean 4 days ago | parent | prev | next [-] |
| Please don’t conflate limited updates with subscriptions. The problems with subscriptions are that the company can take away your own files, the company can take away your software, the lifetime cost is extremely high, and the company can unilaterally change the deal or stop offering one. None of this applies to limited updates offers like Sublime Text’s. You pay once and keep it forever. The three year limit is on the time into the future for which the company continues to add to what you’re keeping forever. Of course this isn’t unlimited, it’s pay once for the program, not pay once for the lifetime servitude of everybody who works on it. |
|
| ▲ | awill 4 days ago | parent | prev [-] |
| It does look like ST is lost here. They don't know where to go next.
But I do like their Sublime Merge product. It's really good. |
| |
| ▲ | kamaal 4 days ago | parent [-] | | That no major AI players even bother to announce a ST plugin/package is proof enough, its now just a tool to manage random text copy/paste snippets. vscode seems to have totally taken over dev mindshare these days. | | |
| ▲ | skydhash 4 days ago | parent [-] | | They also don’t bother to announce a Vim or Emacs one either. VS Code provides good default and most people don’t care about editor fluency. Which is why they keep using it. | | |
| ▲ | kamaal 4 days ago | parent [-] | | >>They also don’t bother to announce a Vim or Emacs one either. vim has a universal and in many ways a eternal use case. You have to edit a file at some point on a server, be it a self hosted or even on ec2. Thats kind of the only real use case for vim. In these days of AI assisted coding, no one really 'edits' code. A lot of editor short cuts and fluency related concepts kind of in many ways are not relevant in this paradigm. The thing is vscode just works, like just works, for nearly all the usecases. In case of emacs, learning it and mastering it takes lots of time in ones career. In case of vscode you don't have to do this, you can straight away work on the project that you want to get done. emacs is some what like a massive distraction from the actual task you want to achieve. Instead of writing code to build a project, you have to first write code to make emacs work, then use emacs to write the project code. In vscode you just write project code. | | |
| ▲ | skydhash 4 days ago | parent | next [-] | | I don't know if you're trolling or not, but there's one thing that VSCode and nearly all other "normal" editors don't have and I want: Non-tied Windows (pane) and buffers (opened files). One of my most used layout is one main window and two smaller ones. Layout like this are my mental frame, but what I actually want to look at may vary at any moment. It may be a test result, a git diff, or going down a reference link. It's like a moodboard instead of a stack of paper you can only look at one at a times. Emacs and Vim has this built-in. Other editors kinda have that, but it's clunky. I can suffer IDE because they provide a lot more than editing. > Instead of writing code to build a project, you have to first write code to make emacs work, then use emacs to write the project code That's only done once. It's like adjusting the mirrors and seats of a car. Once it's comfortable, you don't have to touch it. Using VS Code feels like borrowing a car with a very limited range of adjustments. Why is the explorer on the left and the terminal at the bottom? Why are they always there? | |
| ▲ | iLemming 4 days ago | parent | prev [-] | | Have you even ever watched someone experienced using Emacs or you're making assumptions on your (I suppose limited experience)? The "distraction" framing assumes everyone has the same preferences and working style, I for one find VSCode (and IDEs in general) massively distracting from productively solving many tasks. No, it's not "a skill" issue - I have used InteliJ every single day for almost a decade, diving into some profoundly advanced and non-documented features, and I do open VSCode from time to time. I feel your argument conflates initial learning curve with ongoing productivity, and assumes VSCode's approach is universally optimal rather than just different. | | |
| ▲ | kamaal 2 days ago | parent [-] | | >>Have you even ever watched someone experienced using Emacs or you're making assumptions on your (I suppose limited experience)? I am one of those experienced Emacs users myself. Wrote more stuff in Emacs and even vim than most devs today will even write code over their careers. Its just vscode now does simply too many things out of the box, you obviously can recreate that in Emacs, but its a pointless exercise. Time consuming, and distracts your from your real job. My job is to write code, not build emacs to write code. I totally stopped using Org-mode, because Google docs do it way better. At some point you have to move on. For some people like that point arrived a little early. | | |
| ▲ | iLemming 2 days ago | parent [-] | | > Wrote more stuff in Emacs Can you name Emacs packages you've authored, maintained or contributed to? > vscode now does simply too many things out of the box Oh yeah? Can you edit your filesystem in VSCode like a wiki? Changing directories and filenames as if you're editing plain text? Can any of thousand of its extensions provide "indirect buffer" experience? Can you bind a double tap of the comma to navigate to the last error and automatically fix it? Can you at all bind to double/tripple comma or just about any arbitrary key based on context in VSCode? Keyboard macros with counters - e.g. to transform lists into numbered lists? True buffer based (not file oriented) workflows? Occur-mode style search and replace? Comint style process interaction? Are there any extensions that allow you to move the cursor to the piece of a plain text like "rfc-3540" or "myproj#4044", intelligently recognize it and allow you to browse the RFC document or review a Pull-Request - Emacs does. Can you run a shell command and pipe it into a buffer, or pipe the content of a buffer through series of shell commands and into another buffer? > I totally stopped using Org-mode, because Google docs do it way better. Don't be ridiculous. They are completely different classes of products. If you are even having to compare Org-mode with GDocs, perhaps you don't know well either or both. GDocs can't manage my dotfiles. I can't use it to annotate books or academic papers. I can't have inline LaTeX formulas in GDocs. It can't let me control a videoplayer and type my notes at the same time. I can't use it to manage my flashcards or keep the log of my LLM interactions there. I can't have executable blocks of code - in org-mode I can explore APIs or send SQL queries while passing them into data transforming code blocks. There are no TODO states/keywords in GDocs, no agenda views, no scheduling/deadlines, no time tracking/clocking, no habit tracking, no pomodoro timers, no dynamic time tables, no tag-based filtering, no capture/refile system. > At some point you have to move on Like I told you already, you're assuming too broadly. Both VSCode and Google Docs are excellent products - no denying that, but they are not universally better. If you came to the opposite conclusion, it is yours, and yours only. |
|
|
|
|
|
|