111–120 of 186 posts
Or just use Vim. Not sure I understand the obsession with VSCode.
Have you had a good debugging experience with (neo)vim? I'm the author
Earlier quoted context omitted.
Makes me glad I stuck with vim. I do pretty much the same thing as you, what made you use vscode in the first place? What are the coolest features in your context?
VS Code has a strong plugin ecosystem, and is built around plugins. You can find plugins for everything, so whatever linting, code formatting, back end integration, custom renderers, menus, etc you want you can build and plug in if they aren't available already. Beyond that access to a project tree view / definition list toggle on the side, debug code at cursor, context menu options to refactor/find usage/etc, and ea…
I would be surprised if emacs couldn't do the same.
BTW if VSCode is slow for you, check what extensions you have installed.
Yeah, for me it's more than fast enough except for the Microsoft pylance and C# extensions, both of which I really need to feel productive, and both of which (especially pylance) make VS Code much slower and buggier. It has been getting bad enough that I've been looking around for other editors, but as far as I can tell VS Code really wins on having all the language features, plus copilot and git integration in a sin…
For large project it doesn't scale as well, which is where Rider comes into play, I still daily drive VSC as the editor since it's just way snappier and more fluid than Rider.
Could have just used Visual Studio if you/re deep in C# lol
A lot of developers have moved on to Rider or VS Code + Rider combo nowadays.
Earlier quoted context omitted.
Not having an exclusion for a development directory is like using a 10yo machine or using a laptop without the power brick connected: it’s basically leaving half the perf on the table. Still, a second seems a bit much for a real-time scan.
Clearly you do not work for corporate America. Any amount of performance loss is acceptable to check a security compliance checkbox somewhere.
So anecdotally (N=1) it’s not automatically horrible in US orgs.
Earlier quoted context omitted.
people often overlook accessibility and other essential features of a modern editor, you telling me that your rudimentary rust editor is faster than vscode? and? people don't use it because it's fast (it's not).
How is accessibility an essential feature? I'm not disabled, so I don't care if editor is accessible or not. I care about my use-cases. And I use vscode precisely because it's crazy fast.
I use vscode for doing devops-y things (Terraform, OpenTofu, JSON, python, yaml, txt, dockerfiles, etc.) and sometimes the way it bogs down my system drives me bananas. I'll punt to Sublime Text on occasion and use it for a few days, but then start running into papercuts in various places and have to go back to vscode. I so, so wish there was a better way to do this without fucking electron.
Could have just used Visual Studio if you/re deep in C# lol
Earlier quoted context omitted.
How is accessibility an essential feature? I'm not disabled, so I don't care if editor is accessible or not. I care about my use-cases. And I use vscode precisely because it's crazy fast.
You're not disabled yet . But you may want to care about this before your eyesight, motor accuracy, etc. start failing. It's not some big "disabled/not" switch - setting the font 1pt higher is accessibility, changing the colours is accessibility, being able to tab through fields consistently is accessibility, etc.
On the flipside, I recently had to make some changes to a ~1.5GB XML file, like in the middle of the file. I had a sudden flashback to the Atom editor, which developers considered a 1MB XML file as "large", and hence it totally chocked on a 100MB one I tried once, crashing out after eating 8+GB of RAM. To my mild surprise, it opened in a few seconds, and while all the fancy checking stuff got disabled, basic syntax h…