Sublime text is what notepad++ wished to be. There are many tasks that do not require a full IDE, not even vscode and sublime just works. Always, consistently, reliably works, is fast and a joy to use.
Objectively, Notepad++ is inferior at cross-platform support. Subjectively, I don't like that the creator of Notepad++ uses the software itself as a platform for his politics. In either case, I prefer Sublime.
Notepad++ is like if Word 98 and IrfanView had a baby, a baby who updates twice a week. No disrespect to any of them, but having a clean interface and killer performance was never their claim to fame.
Are you kidding me!? You can have hundreds, even thousands of tabs of files of any size open in Np++, close without saving, and yet get back instantly on the same session when you start it up next time. Notepad++ is literally faster than Microsoft's own native Notepad, let alone Sublime Text. Even 50GB csv files open instantly in Np++.
Zed pretty much copied everything over from Sublime, so it's pretty much on par.
Sublime was one of the first editors to have an uncluttered UI without toolbars, but with advanced features, like multi-cursor editing and the command palette.
As a long time sublime users, it still feels superior as it gets lots of small details right, like for example when I do Cmd+P to search for files and scroll through the files it will show a preview, Zed doesn't show a preview until you actually select the file.
Yup, I used TextMate a lot back in the early 2000s, and Sublime from around 2010 and bought a license maybe a year later.
To this day I always install Sublime on my new machines, it's the perfect text editor for my needs: fast and snappy, buffers are persistent so I can use as a scratch pad without having to save files, can customise with plugins if needed, the command palette gives quite a bit of power user features.
I mostly use it as a scratch pad nowadays, like if I'm debugging something, collecting a bunch of text from different places to reference quickly, nothing too advanced (nor directly related to coding) and is still one of the most satisfying programs to use on my day-to-day. It's basically always open, just waiting for a new buffer.
Technically correct. However, for the majority of humans, their first encounter with these features and behaviors could never be TextMate, and instead would be Sublime Text. TextMate never growing to be cross-platform is a major reason for Sublime Text's early growth.
I use Sublime mostly these days but I still have a soft spot for TextMate. Sublime is the closest that exists to its spiritual successor, but it’s missing the “macness” that TextMate brought back in the day, which is the cost of being a cross-platform app I suppose.
I’m using Zed, but I honestly can’t recommend it to anyone yet. They claim 1.0 but in reality it’s still beta software. It is fundamentally broken in how it deals with the file system so the project panel and git panel can easily miss changes, and it’s still not clear if they’ll even address it.
At least it seems the next release might fix the bug where the git panel will jump to a different repo when you click on a file in it. They should seriously have fixed basic stuff like that before releasing 1.0. But they got in lots of cosmetic changes to the markdown viewer.. they really need to consider their priorities
We put a fair amount of effort into reducing our resource footprint, so I'm curious what you find lacking in our memory management. From a quick test we use a similar amount of memory to Zed.
Hard to compare the two programs over a week of uptime. ST memory usage does get larger as caches get filled over time, but I've had uptimes of months without issue. I'd expect similar results from other editors.
Do you have a specific memory issue where it keeps using more over time?
General issue, have observed it on multiple systems. On a long enough timescale, will grow to farcical amounts of memory usage.
Unfortunately, while this is something I've observed through major point releases and on different platforms, there have always been some plugins in use.
UnUnfortunately not enough commonality in configuration or hours in the day to track down if this would happen on a totally clean install...
I'm sure your roadmap is quite extensive, but it would be great if sublime itself could graph or warn when memory usage increased by some specified percentage, or if any particular plugin spikes resource usage.
Plugins are a frequent culprit of issues like this. Depending on how you're tracking memory usage you may already be able to at least narrow down the culprit by looking at which process is using too much; plugins run on a separate process and may launch additional processes from there.
Unfortunately tracking individual plugin memory usage is not possible without invasive (and slow) tracing. If the plugins are causing big memory usage in the main process it can be hard to nail down due to that state being shared between all plugins.
Zed has no real plugins, and its core isn't as advanced enough as to not require them (though given the infinity of workflow variety, unlikely to ever be), it's bloated in comparison, and has a few more broken basics (like not properly tracking externally changed files)
I started using Zed daily about 6 months ago after 10 years of VS Code. VS Code was having idiotic regressions (like randomly inserting a copy of the final line of a file on save) while they were busy pumping out AI features.
Turns out, Zed is also busy pumping out AI features and the code editing experience is degrading. I'm actively shopping for a replacement.
Sublime Text doesn't automatically download and run language servers without your consent. Zed does, and last I looked there's no way to turn that behavior off (the devs said it's an intentional decision to make things easier for users). I am personally of the opinion that it isn't acceptable for software to start pulling in other software without my consent, so I avoid Zed like the plague. The Gram fork of Zed is pretty good, though.
Prisoner’s dilemma: margins are razor thin. If your fellow farmers use better seeds then you are forced to use them as well. Otherwise you won’t be able to match their prices without selling at a loss.
That's true of any productivity enhancement. If your neighbors use more efficient tractors you're at the same disadvantage, but nobody argues that farmers should be able to steal tractors.
The parent has to do with permission, not stealing. Imagine if your neighbors could have an exclusive license to buy the new obviously superior tractor which you will never be able to obtain no matter what you do, simply because you're not them. This is legal today, the argument is that it shouldn't be because it punishes competition and lets the rights-holder wield too much power over the market.
Only if the cost of monsanto seed + roundup is less than the cost of regular seed per expected harvested bushel? Otherwise, no one would use the monsanto seed + roundup?
Who designs a signaling system where a ‘major disruption’ can be caused by a jumper cable applied at any point along potentially hundreds of kms? What about resiliency and fallbacks for something that critical?
Fear not! I’m sure the European Commission will promptly ban jumpstart cable ownership without a license.
The big bet is that the LLMs will get good enough to invent new frameworks or even branches of math. I hope it pans out. Otherwise we will get stuck in a local maximum for a while.
On the positive side We won’t get the cars, but our horses will be damn fast ;)
> Debian is a large and complicated project: the release announcement for version 13 says it has 69,830 packages, which take a total of 403 GB of disk, and contain 1,463,291,186 lines of code. So, suitably, it is a large and complex poll.
Surely these are not just Debian-owned packages. Whatever Debian decides won’t apply to packages not owned by Debian
Debian is huge - that's why so many other distros use it as a base!
So, yes, all those packages are maintained either by an individual Debian Developer or a team of them.
There are third party repos, but they're (currently) neither as widespread nor as commonly-used as those for other major distros. This vote won't affect them, and you might potentially expect to see their use grow if one of the harsher options in this GR were to pass.
Sure, this is (mostly) about direct contributions to Debian.
Proposal C does discourage use more broadly but acknowledges that many upstreams take a different view and that it would be impractical to ban them from using it.
reply