I don't really know what you do with your text editor, but Emacs (and vim) are very much not "low-level" editors unless you chose to not configure them.

Emacs has all the features of VScode, plus more. And it keeps expanding by each day. A "fully featured" Emacs "IDE" is also just as laggy, sometimes even more, as any other "fully featured" IDE. Some Emacs configs even take tens of seconds to load! Mine however takes 1.5s, but that is because everything is lazily loaded. The first time I open a C++ file, it takes a couple seconds.

A really nice easy to use framework for getting productive in Emacs quickly is Doom[1]. You should give it a peak if you think Emacs is "low-level".

[1] https://github.com/doomemacs/doomemacs

What is doom equivalent in vim?

I took the same journey. I switched from Sublime Text to VSCode and stuck with VSCode for months, and depending on project du jour I've done this a couple of times. For me its mostly speed and a number of small, but frequently encountered, quality of life issues that keep me coming back to Sublime Text. Some of the small differences around cursor/multi-cursor management never stop irritating me in VSCode compared to ST. Also, I do a lot of PostgreSQL related stuff and I've yet to find a syntax highlighter that's 1) just syntax highlighting; and 2) able to handle things like dollar quoting well for VSCode where in Sublime Text I've had such highlighting for years.

Sure it doesn't see frequent updates... but so what? That might well be a strength since some kinds of changes can be low value & highly disorienting. The plug in eco-system isn't as broad as that for VSCode, but unsurprisingly there's more cruft there, too.

Ultimately your mileage will vary based on your preferences, but I'll stick with Sublime Text until there's something really more compelling.

Interesting, it was mutlicursor bugs in SublimeText that never got fixed the drove me to finally switch to VSCode.

ST dev here, what multicursor bugs specifically?

> ST dev

Just wanted to say thank you for a fantastic text editor. It feels like a superpower when I show it to non-tech people

> Just wanted to say thank you for a fantastic text editor.

This. ST has been my best coding tool for the last few years. A keeper. Thank you!

Here's an annoying one: https://github.com/sublimehq/sublime_text/issues/1054

ah yeah, that one has me disabling word wrapping on files where I wouldn't otherwise.

Hasn't been enough motivation to leave ST though

First off, thanks for years of productive development with ST. I really enjoyed using your software for a long time and it carried me through a significant portion of my early career.

It was a bug where selecting some text and using the key shortcut to multi select the next instance would select incorrect text for certain strings. It was a while ago so I don't remember the details, it may have been some combos of whitespace and non-alphanumeric characters.

It wasn't the only reason, but it was the final impetus to try some other solutions.

> A computer just shouldn't need several seconds to load and parse a source file even if it has 100.000 lines.

Why? It doesn't just load the file, but also analyze it, find flaws and put it into a bigger picture which assists the user. And you don't need a last gen for this. I work on a 10 year old machine quite fine with a rather heavy IDE-Setup. Just accept that a computer can be your partner, helping you to reach your goal, and that he needs his time for doing his work too.

I love these weird, artificial "no true Scotsman" arguments that appear on HN when people are discussing little more than the colour of the bike shed. "Oh, but how does it do with 100k lines?" I can already tell you from my lovely, bloated IDE: Terrible. And, I don't care. Why? WTF is this file 100k lines!?

I know at my workplace, the vim&emacs-users are the reason for the codesinks here. They have no relevant penalty for growing everything in singles files, but they have some benefit as they can navigate code better with a poor setup. And at some point, reasons like "not destroying the git-history" and such are added to the list. And laziness might be another reason on that list.

Because your are not viewing those 100k lines at once ever. Taking that into consideration, enormous optimizations are possible.

The lines are all interconnected. Whether you view them or not, they still influence each in some way or another. And figuring this out is the hard part in coding and software-design, which the computer takes care of and assists you.

All the lines being interconnected is a rare edge-case. Often there are multiple independent top level expressions in a file. Talking about code here, because that is the most common thing that needs to be highlighted and where lines influence each other potentially.

To make a simple example: Have multiple functions defined at the top level of the file? Great! Independent parts!

Of course it could be, that in one function another is called, but does that have to affect highlighting? Immediately?

The code model still needs to be built from the entire file, which I suspect is what most of the slowdown is when using an IDE (not highlighting, although the code model can inform advanced highlighting e.g. different colors for local vs instance vars).

Well, that is no justification for any slowdown. The "code model" does not need to be complete the moment I start an IDE or open a file or project in it. A temporarily incomplete model is very acceptable. More work can be put off to a background thread. It can be delayed until I perform the first action, that actually needs a complete model, like say a renaming of something. There are relatively few actions like that. Many facts can already be concluded from import statements in various languages.

Furthermore we are fighting a strawman here: Who in their right mind opens a 100k line code file in an IDE? And who in their right mind creates such a disaster in the first place? This is not a realistic scenario we are talking about here.

After all these years, sublime still stands on a league of its own.

Fleet is supposed to be this lightweight editor but unless it can beat sublime at startup, it's not.

One of only about three things I miss from switching away from Windows, is that I now have to use Sublime instead of Notepad++. It was just so much better at dealing with large files and batch operations, which are a priority for my work. But Sublime has beat everything else I have tried out on Linux, and obviously has features Notepad++ does not.

I tried to switch from Sublime to VSCode as well, and it's mostly been a disappointment.

I'm in the market for a new IDE as Atom is end of life (prev. Sublime)

I tried VSCode and went back to Atom -- it still works fine but expecting that won't last

Ideally I really need one where I can run bash sessions in tabs alongside code, I don't really use autocomplete and such -- but it needs to handle a lot of open large files with zero lag and instant search

>Ideally I really need one where I can run bash sessions in tabs alongside code,

Wouldn't it easily be solved if people were actually using decent desktop environment or take the time to configure it correctly?

I mean it is not complicated to move from ide to terminal if the desktop and shortcuts are well made.

I moved from Atom to VSCode a few years ago. It's a worthy successor, in my opinion.

What were your blockers to moving to VSCode? My remaining issue is to be able to css style any element of the UI like I could with Atom. There're plugins that let you monkey patch to get that feature, but updates to VSCode break them.

Too many windows, panes, misfeatures I don't want, and it's also quite slow.

It's a kitchen sink even before you install any plugins, and yet all the useful functionality requires plugins.

All I want is a text editor that can quickly switch to another file, that doesn't make it annoying when the file it had open was changed, that only adds the input that I type to a file and nothing else.

Also easy integration with commandline tools (select text, pass that as stdin to a command, replace it with stdout, all done trivially without going through a billion menus and plugins), vertical selection and multi-cursor that doesn't suck, maybe a few other details, are things where it failed to deliver.

I switched from Atom to VSCode a while back. Code has better extensions and is faster. Only thing that bothered me is the missing Git view on right side. But now Code lets you have a Primary and Secondary sidebars. I keep Git on right side and File Explorer on left side

I think Pulsar might be interesting: https://pulsar-edit.dev/

I understand these are some folks trying to keep Atom alive.

Vscode now allows terminal to be in editor area along with files.

All the code I work on is hosted on a separate development server, so I used to use Sublime to edit these files over the network, using NFS.

But now I use code-server, which is hosted on the same development server. So everything got a lot faster for me.

Really? I did the switch and there’s no way I could go back to ST.

Sublime still feels a bit snappier to me. The ecosystem around it has obviously fallen behind a bit now though.

Only partially true. The ecosystem has some really awesome plugins: - GitSavvy - Sublime-LSP (plus LSP-Copilot) - Sublime_Debugger - Terminus

All these together and you have a keyboard driven ultrafast IDElike experience.

Agreed. I loved Sublime for years but VS Code is now miles ahead in my opinion.

In what ways do you think VS Code is miles ahead? With language server and debug adapter plugins, I find ST to be a very good replacement for VS Code.

For me it is the plugins, themes, icons etc. As soon as there is a plugin you can't live without, there's no way back. I can't remember which one it was for me but when I saw a co-worker using it I had to give VS Code another try.

Migrating over is easy too as you can import your shortcuts with "Sublime Text Keymap and Settings Importer"

All the plugins, The synced user configuration, github copilot, git integration (although I do use sublime merge a lot on the side), I used to work on a remote copy also via SSH (and I can't remember what plugin), there's just so much available out of vscode now, I feel like every new months it ships new features while sublime text didn't come up with an update in years.