I'm still on Sublime Text, after briefly switching to VSCode. Unless you're on latest-gen hardware it seems that most feature-rich IDEs are just terribly laggy, which drives me nuts. A computer just shouldn't need several seconds to load and parse a source file even if it has 100.000 lines. Editors like Emacs or Vim were always too low-level for me though, Sublime is a nice compromise between simplicity and speed.
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".
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.
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.
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.
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'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
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
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.
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"
