6 ms·

The original author of the bracket colorizer extension gets a great shout-out in this post and was also involved in the discussions of building the feature. Mo

The original author of the bracket colorizer extension gets a great shout-out in this post and was also involved in the discussions of building the feature. Moreover, he has stated that he was tired of maintaining the extension and seems to be fully in favor of this move: > Author of Bracket Pair Colorizer here. > I follow this thread with interest, my extension is something that grew a bit out of control, and I grew tired of maintaining it. The comments here suggesting that the Visual Studio Code team was somehow wrong for making this improvement or that they otherwise wronged the extension author are not reflective of the actual process nor even the extension author’s own feelings. The blog post does a great job of describing why bracket colorization isn’t appropriate for the plug-in architecture anyway. Making it fast can only be accomplished within the core of the editor code which has more direct access to syntax parsing. This is a win for everyone all around. The Code team did a great job with this feature and the associated blog post.

duxup 5y ago
We see a lot of situations where things sort of die or fade away when the author(s) just don't have time. This seems like the ideal situation where a highly capable team takes over and the author is happy to see it.
- int_19h 5y ago
  The single most popular extension for VSCode - the one that adds Python support (https://marketplace.visualstudio.com/items?itemName=ms-python.python 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-microsoft/ 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 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.
  - duxup 5y ago
    >Curiously, some bits of code went kinda full circle in the process "Oh I see why. .. yeah that's a better idea." Happens to me all the time ;)
    - sillysaurusx 5y ago
      Code going full circle is the basis for multiplying coding estimates by pi: https://news.ycombinator.com/item?id=28667174 https://news.ycombinator.com/item?id=28667174
    - int_19h 5y ago
      Not in that sense. The VSCode extension didn't fork the debugger in question - it took the original code verbatim, and simply wrapped it into a DAP adapter. Ironically, when we rewrote the Python debugger later, we did the same exact thing with pydevd (https://github.com/fabioz/PyDev.Debugger https://github.com/fabioz/PyDev.Debugger), and for the same reasons - why reinvent the wheel when you can take an existing one that's already better than anything you have? It's also better for the ecosystem, since improvements all flow upstream.
seanw444 5y ago
Well, if the author ever reads this post, thanks for making an extension that I used every single time I installed VS Code. Was a no-brainer every time. Glad to see it implemented by the core team.
mzs 5y ago
indeed, thanks: https://github.com/microsoft/vscode/issues/128465#issuecomment-879195058 https://github.com/microsoft/vscode/issues/128465#issuecomme...
jareklupinski 5y ago
I agree, but I think at least some of the animosity stems from how the author might not have been able to do this themselves if they wanted to: > Without being limited by public API design, we could use (2,3)-trees, recursion-free tree-traversal, bit-arithmetic, incremental parsing, and other techniques to reduce the extension's worst-case update time-complexity (that is the time required to process user-input when a document already has been opened) from \mathcal{O}(N + E)O(N+E) to \mathcal{O}(\mathrm{log}^3 N + E)O(log 3 N+E) with NN being the document size and EE the edit size, assuming the nesting level of bracket pairs is bounded by \mathcal{O}(\mathrm{log} N)O(logN). just hurts to see after having been burned by Apple's private APIs blocking legitimate app developers from doing something Apple will release next cycle themselves, even if it was to everyone's benefit and a net positive
- dariusj18 5y ago
  Yes, but I feel like extensions are not considered "apps" in a way that would make people feel they should be able to write anything they want to change the editor. That way lies madness.
  - yaantc 5y ago
    > That way lies madness That way lies Emacs ;) That's the key difference between Emacs and most other editors: there's no limited API for extensions. There's a base C runtime, and all the lisp code on top is at the same level. There is no difference in access rights between a core Emacs package (coming with Emacs) and an additional, user installed package. Of course, there are a lot of documentation, conventions and best practices to support this. And all the code is accessible.
    - mastax 5y ago
      What happens when multiple packages want to modify the same code?
      - derefr 5y ago
Aeolun 5y ago
I don’t think the blog post does a good job of letting us know they communicated ‘hey, we gun make this core’ before they decided to do it (and release this post).
bravetraveler 5y ago
In video game terms, this seems like getting upset about Valve with Counter Strike. Started as a Half-Life mod, became something much bigger.

duxup 5y ago

We see a lot of situations where things sort of die or fade away when the author(s) just don't have time. This seems like the ideal situation where a highly capable team takes over and the author is happy to see it.

int_19h 5y ago
The single most popular extension for VSCode - the one that adds Python support (https://marketplace.visualstudio.com/items?itemName=ms-python.python 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-microsoft/ 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 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.
- duxup 5y ago
  >Curiously, some bits of code went kinda full circle in the process "Oh I see why. .. yeah that's a better idea." Happens to me all the time ;)
  - sillysaurusx 5y ago
    Code going full circle is the basis for multiplying coding estimates by pi: https://news.ycombinator.com/item?id=28667174 https://news.ycombinator.com/item?id=28667174
  - int_19h 5y ago
    Not in that sense. The VSCode extension didn't fork the debugger in question - it took the original code verbatim, and simply wrapped it into a DAP adapter. Ironically, when we rewrote the Python debugger later, we did the same exact thing with pydevd (https://github.com/fabioz/PyDev.Debugger https://github.com/fabioz/PyDev.Debugger), and for the same reasons - why reinvent the wheel when you can take an existing one that's already better than anything you have? It's also better for the ecosystem, since improvements all flow upstream.

seanw444 5y ago

Well, if the author ever reads this post, thanks for making an extension that I used every single time I installed VS Code. Was a no-brainer every time. Glad to see it implemented by the core team.

mzs 5y ago

indeed, thanks: https://github.com/microsoft/vscode/issues/128465#issuecomment-879195058 https://github.com/microsoft/vscode/issues/128465#issuecomme...

jareklupinski 5y ago

I agree, but I think at least some of the animosity stems from how the author might not have been able to do this themselves if they wanted to: > Without being limited by public API design, we could use (2,3)-trees, recursion-free tree-traversal, bit-arithmetic, incremental parsing, and other techniques to reduce the extension's worst-case update time-complexity (that is the time required to process user-input when a document already has been opened) from \mathcal{O}(N + E)O(N+E) to \mathcal{O}(\mathrm{log}^3 N + E)O(log 3 N+E) with NN being the document size and EE the edit size, assuming the nesting level of bracket pairs is bounded by \mathcal{O}(\mathrm{log} N)O(logN). just hurts to see after having been burned by Apple's private APIs blocking legitimate app developers from doing something Apple will release next cycle themselves, even if it was to everyone's benefit and a net positive

dariusj18 5y ago
Yes, but I feel like extensions are not considered "apps" in a way that would make people feel they should be able to write anything they want to change the editor. That way lies madness.
- yaantc 5y ago
  > That way lies madness That way lies Emacs ;) That's the key difference between Emacs and most other editors: there's no limited API for extensions. There's a base C runtime, and all the lisp code on top is at the same level. There is no difference in access rights between a core Emacs package (coming with Emacs) and an additional, user installed package. Of course, there are a lot of documentation, conventions and best practices to support this. And all the code is accessible.
  - mastax 5y ago
    What happens when multiple packages want to modify the same code?
    - derefr 5y ago

Aeolun 5y ago

I don’t think the blog post does a good job of letting us know they communicated ‘hey, we gun make this core’ before they decided to do it (and release this post).

bravetraveler 5y ago

In video game terms, this seems like getting upset about Valve with Counter Strike. Started as a Half-Life mod, became something much bigger.