3 ms·

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

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/ 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.

deleted 5y ago
[deleted]
vbezhenar 5y ago
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.
- db48x 5y ago
  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.
- tikhonj 5y ago
  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.
Zababa 5y ago
VSCode being open source, I wonder if you could build an ecosystem of extensions that don't use the extension API but have full access.

deleted 5y ago

[deleted]

vbezhenar 5y ago

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.

db48x 5y ago
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.
tikhonj 5y ago
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.

Zababa 5y ago

VSCode being open source, I wonder if you could build an ecosystem of extensions that don't use the extension API but have full access.