4 ms·
> I had the impression VSCode had the technical superior plugin system From my very limited exposure to VSCode's plugins, it seems they are a lot more limited
by grumdan 8y ago
> I had the impression VSCode had the technical superior plugin system
From my very limited exposure to VSCode's plugins, it seems they are a lot more limited in how they can change the editor's behavior compared to elisp code in Emacs[1]; if Atom plugins are similarly flexible, then I'm not sure you can say it's (strictly) technically superior if you can only implement a small subset of what you can do in competitor's system. At most it's better at some tasks and worse at others if this is the case.
[1] I didn't say "Emacs plugins" since there is no distinction between user-written elisp code and core editor elisp code and you don't need to create any plugin project or such, which I think makes for a much more organic and pleasant customization experience.
- k__ 8y agoI meant superior to Atom and not to Emacs. As far as I know, the VSCode plugins run in their own process, which makes the editor much more responsive when it loaded many plugins.
- grumdan 8y agoI was assuming that Atom extensions were similarly powerful as in Emacs, if that's not the case, then my point is moot. I agree that restricting what plugins can do can lead to better stability and speed at the expense of extensibility.
- oblio 8y agoTechnically superior could mean in this case that a rogue plugin does not affect the core editing experience. Having a fixed extension API, if the API is well done, could provide that. You lose flexibility, you gain stability, discoverability, speed, etc.