If you can make something 10k x faster you didn’t so much fix it as just switch it to working correctly as it should have in the first place.<p>VSCode is a good tool, but it’s unbearably slow, and it breaks my heart that so much development has converged on something written in electron with such a low regard for performance by any measure.
Everyone saying "This isn't a speedup, this is VSCode stopping being dumb" hasn't read carefully enough:<p>The speedup is from taking extension code built on a limited API and implementing it inside VSCode, using more information while doing so.
Odd to read that "While we would have loved to just improve the performance of the extension (which certainly would have required introducing more advanced APIs, optimized for high-performance scenarios), the asynchronous communication between the renderer and the extension-host severely limits how fast bracket pair colorization can be when implemented as an extension. This limit cannot be overcome." Especially when I try out "rainbow-delimiters" in emacs and see that it is already quite fast.<p>I can kind of buy into the idea that "async by default" is a good path to build plugins. It boggles my mind that some of these slownesses are just lived with, though. How many other plugins that haven't gotten the attention of the core team can never get sped up, because of this choice?
2021<p>already submitted two years ago (268 comments)<p><a href="https://news.ycombinator.com/item?id=28692470">https://news.ycombinator.com/item?id=28692470</a>
I suspect that one of these days someone will just bite the bullet and write an abstract syntax tree editor, and eliminate at a stroke all of the "first, we turn the text into an abstract syntax tree" steps that occur in everything from code colourization through folding to code suggestions. (-:
One thing I miss the most from Xcode is the ability to double-click on any delimiter pair ([...], (...), <...>, {...}) to select all text between those delimiters.<p>I filed an issue against VSCode to get this implemented, but it never got enough upvotes..<p>Maybe posting about it here is my chance to get it done? :-P<p><a href="https://github.com/microsoft/vscode/issues/85587">https://github.com/microsoft/vscode/issues/85587</a>
When working on an experimental VSCode plugin recently, I noticed that bracket colorization was at odds with some basic functionality. For example, in comments, I didn't want colorized brackets, I just wanted everything in the same color. That wasn't possible, except for switching the native colorization off completely. Which I did.
I'm sorry but I still prefer sublime text, and it finally fixed syntax folding!<p>Sublime text also has a cheap way to do auto-completion, it will just look at existing words in the current file, it's often just enough.
I recently noticed, that code window scrolling is a bit smoother and faster with terminal window closed. Could this be one of those "10kx faster" opportunities?
And now make something more production oriented like multi-screen window support, whoops you can't and you buried this feature request in your github. GG.
And yet, somehow, no one has done anything to address the inherent issues for colorblind developers. All of these colorization add-ons are woefully inadequate in that regard.
But these "micro optimizations" aren't going to win anything!<p>Just keep everything slow and then everything will be alright.<p><a href="https://news.ycombinator.com/item?id=36401488">https://news.ycombinator.com/item?id=36401488</a>