Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
nvim-ts-rainbow
Discontinued Rainbow parentheses for neovim using tree-sitter. Use https://sr.ht/~p00f/nvim-ts-rainbow instead
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
Igelau linked to this thread: https://github.com/microsoft/vscode/issues/128465#issuecomme...
In it, CoenraadS (the extension developer) writes
"I follow this thread with interest, my extension is something that grew a bit out of control, and I grew tired of maintaining it."
and
"If it could that would be great, and my extension could be deprecated completely."
There was also discussion with the author about updating the extension to prompt users to switch to the native functionality, and it appears CoenraadS was also involved in the process/design of implementing the feature in VS code.
This appears to be a shining example of doing it right, and giving the original extension author credit.
> Constructing or incrementally updating an AST is not cheap. In particular, most ASTs are very fragile and there are characters when inserted at the wrong position invalidate the entire AST (e.g. prepending a C-like document with `/*`). Even prepending documents with `{` could render all nodes of the AST invalid, as they might get a different meaning (a class declaration might now be parsed as block statement).
I think you have a worldview where text is being edited and ASTs are constantly being replaced via parsing.
In an AST-based language, it doesn't necessarily have meaning to add some random character at some random spot, in the way that it does with text. With text, you can only recreate the entire AST by parsing, and discover that the parse is broken.
With an AST-based language (such as https://darklang.com), the editor could inform you that that character cannot be added in that place. Or it could allow you to put it there, informing you that that particular piece of text has no valid meaning, while the rest of the AST is still valid. (Darklang uses both approaches).
The original developer doesn't sound too worried and seems to have collaborated on the feature: https://github.com/CoenraadS/Bracket-Pair-Colorizer-2/issues...
Plus it helps him getting rid of 399 open issues.
I've been using a TreeSitter-powered colouriser in Vim, it's fantastic and, like with everything TreeSitter related, extremely fast.
https://github.com/p00f/nvim-ts-rainbow
This article is especially interesting to me, as it shows how VS Code still doesn't have the "Emacs nature". Even though I'm a 30-year Emacs user, I do hesitate to recommend it to younger programmers because it's so alien, and VS Code has one of the essential characteristics of Emacs: the extension language and the implementation language are the same. But this article is a great example of how it doesn't — extensions are limited to using an extension API, rather than having full access to the application's internals. Maybe a good thing, if you're a mass-market product worried about malicious extensions. But I'll note that [rainbow-delimiters-mode](https://github.com/Fanael/rainbow-delimiters/) dates back to 2010, and has never noticeably slowed down loading or display of source files, even in languages with lots of delimiters like Lisp.
There is one for emacs. Could be good inspo if someone wanted to make a VSCode version.
https://github.com/alphapapa/prism.el
WebView2 will be coming to macOS then Linux in the not-so-distant future: https://github.com/MicrosoftEdge/WebView2Feedback/issues/645...
I'm not aware of any public plans to move VS Code to WebView2, but I would be surprised if it doesn't happen eventually.
The single most popular extension for VSCode - the one that adds Python support (https://marketplace.visualstudio.com/items?itemName=ms-pytho...) - is somewhat similar: it was originally written by Don Jayamanne, and later acquired by Microsoft. Although in that case, Don was hired by Microsoft as well, and continued working on it:
https://devblogs.microsoft.com/python/don-jayamanne-joins-mi...
This can still be seen on GitHub - if you look closely, the official repo at https://github.com/microsoft/vscode-python is a fork!
Curiously, some bits of code went kinda full circle in the process - vscode-python reused the (open source) Python debugger written at Microsoft for Python Tools for Visual Studio.
Yeah and even in personal config one could use el-patch[1], to make monkeypatching future proof.
[1] https://github.com/raxod502/el-patch
Idea is that in emacs the procedure is a simple function call, so if the "business" logic isn't too expensive (and I presume the Emacs folks have done a good job of ensuring this is true), it will run pretty darn quick. On VS Code it's a whole IPC maneuver, so even if the "business" is fast, there can still be a lot of overhead that bites you when calls happen frequently.
The extension model is the same in VS Code, all the author needs to do is write basic JS (or TS). VS Code core does the heavy lifting of creating the extension host process to run that code and exposing the `vscode` proxy object to the extension's code, which enables communication between the extension and the renderer in a manner that appears identical to as if the `vscode` were a simple object. See the minimal hello world sample [0] for the basic case.
End of the day it's a tradeoff between latency and throughput, emacs chooses latency, vs code chooses throughput. Both have their ups and downs.
[0] https://github.com/microsoft/vscode-extension-samples/blob/m...