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.
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.
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:
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.
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), 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.
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.
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).
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
> 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
What animosity? The animosity other people have on behalf of the author who has clearly said he has no beef with this series of events? If the author wanted to make algorithmic changes like the VS code team have done, I'm sure they would have been more than happy to discuss this on the open source issue tracker (which is very active).
> 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,
The big difference here being that the app developers are happy that this has happened, and they could have attempted to do this work because even though the APIs are private, the source is available and they readily take pull requests.
> The big difference here being that the app developers are happy that this has happened
I don't see why this would make a difference. Say I'm working on a project. There's a hole in my project. And you offer something to fill the hole.
But your action can't then bind me to refrain from fixing my project. Once my project no longer has a hole in it, you've lost a line of business. But you've lost that line of business because it solved a problem that was correctly fixed. The situation now is obviously better than the situation before. If I needed permission from you to fix my own thing, how could that conceivably improve anything?
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.
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.
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.
I think that it's not about malicious extensions. It's about compatibility. If there's no public API, then all API is public and any code change will break something. So you either break extensions or don't change code at all. With public API you can change code while keeping public API working. And if something must be changed, the damage is limited and controlled.
The Emacs maintainers seem fairly conservative about changes to the Emacs runtime, but they have managed a number of extensive changes. It even has JIT compiling now.
Partly this is because the nature of the Lisp language makes these changes easier, but it is also the case that many “extensions” are actually included with Emacs. There are over a 1.5 million lines of lisp code that are included in the Emacs repository, though most of them are not enabled by most users.
Other extensions come from a wide variety of sources (and of course many users write their own code), but over the last 10 years most of them have been moved into installable packages hosted on elpa.gnu.org. There is a little over a million lines of code there.
It takes just a couple of minutes to check out both git repositories (for Emacs and ELPA), so any time you want to change something in Emacs it is quite easy to search all of that and find out exactly what, if anything, you might break.
That's true in principle. In practice, I've seen Emacs undergo non-trivial changes and yet none of my personal Elisp code has ever broken. I'm not sure how that happens—perhaps the core abstractions are sufficiently simple that they don't need to change much themselves and only higher-level things change, so code written against the core abstractions doesn't get broken.
I gotta say, "That way lies madness" == "That way lies Emacs" gave me a good chuckle. But your point is good, there are ways to do it, but VSCode has already started down the road of security first, and the emacs model would certainly not function in a sandbox.
This is. Loser to the original Firefox extension model — pen access to everything. It later limited internal changes as internal stuff was external to extensions. It did allow powerful things like Firebug, which could not be build with todays modern and more secure locked down APIs.
I have only the slightest passing knowledge of ELisp, but I believe it offers Aspect-Oriented Programming (AOP) facilities; most basically, chained decorators (i.e. replacing a function with your proxy for that function, where your definition of the function gets bound dynamically to the current definition of the function at eval-time; so the call your function makes to the “inner” function, could just be to another proxy wrapper function someone else already inserted.)
That is the most complicated description of it I have ever seen, but it is accurate.
In total there are ten ways to combine new advice with the existing set of methods, but the most commonly used are :before, :after, and :around. All the :before functions are called first, then the outermost :around function (which may or may not call the next :around function), then finally the :after functions.
Also it is common to define explicit hooks, which are just lists of functions that you will call at documented points. This is functionally identical to advice, except that it is also a good signal that the author intended you to do so.
The terminology is interesting too. Advice is deliberately modeled after the generic method combinators in Common Lisp. One of the authors of the Common Lisp spec, Gregor Kiczales, went on to define the term “Aspect–Oriented programming” and later developed AspectJ. Although the phrase appears nowhere in the documentation for Emacs Lisp, it is definitely appropriate!
Hmm. I don’t think concision is really the right way to go; below a certain length a description just becomes less precise and useful rather than better. I think that my own description should have had another paragraph or two, looking back at it.
Or maybe we could both be more concise by just telling people to go read The Art of the Metaobject Protocol.
Usually packages don't modify code in core Emacs or in other packages. Often, they use package-supplied "hooks" to add behavior to other packages. Failing that, there's the possibility of 'advising' functions to add/change behavior at certain points without actually monkeypatching. I've never seen a distributed package actually monkeypatch anything, though it is something you could do in your personal config.
You know, I haven't thought much about this. I use a lot of third-party packages and have a lot of my own custom code, but things almost never interfere. In the few cases that crop up (for example, awkward interactions between org-mode's completion and the completion plugin system I use), it was so easy to add some code to my .emacs file to fix that problem that I had no real problems with it.
I used Atom before VSCode. I'm still in love with its minimalistic design and somehow font rendering in Atom better than in VSCode (still not sure why, I tried to play with settings and stuff, but nothing changed).
It was the first prominent Sublime Text alternative with JS that I use every day and quickly wrote my extensions, hack it and play with it.
There were even interesting decisions like a Rust-based rendering engine[1] using graphics without HTML and DOM (the same old problem with faster text rendering with web techs).
In my opinion, the ONE big thing that killed Atom was LSP[2]. VSCode was slightly better in everything, but good performance and LSP destroyed Atom and damaged all other editors (like Sublime).
But MS plays dirty here too. In VSCode, LSP works with many inner hacks. You can't get the same experience with LSP in other editors because some features are part of the editor, not just LSP. But I think LSP is excellent and use it in Emacs and Vim too. For Rust, it's maintained by the Rust team and the default "engine" for editors.
Anyway, I'm still using Atom today with a minimalistic theme and setup to edit markdown files with code and as a text editor with a friendly GUI overall.
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.