[meetups323]

This is, in part, because VS Code plugins run in a separate process. Each extension API needs corresponding IPC code on both the extension host process and the renderer process.

This means that plugins which work great in Emacs, where there's no IPC overhead, might be pitifully slow in VS Code. Alternatively, plugins that work great in VS Code might bog down Emacs (yes, the Emacs plugin can spawn a new thread and work there, but I don't think that's the typical approach of plugin authors)

Note that Extensions are able to directly manipulate the main application bundle a la Emacs (this is what https://marketplace.visualstudio.com/items?itemName=be5invis... does, for instance), but that is discouraged by way of a checksum failure putting "Unsupported" in the title bar. Of course, that checksum code could be removed by the extension too, but doing so without informing the user would be considered in bad taste.

[taeric]

This makes some sense, but I'm a bit confused on why it was so slow, to be honest. Seems that running emacs against the checker.ts example they gave, with rainbow-delimiters-mode is instant. Am I just comparing against a different type of mode?

That said, I do get the point on wanting things to be IPC based, but that feels like a large jump in complexity for most items. I'm very grateful for the model of extension in emacs, where you do have to learn complexities if you are building a complex plugin, but you can go very far before you get into the realm of complex plugin.

[meetups323]

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, largely dependent on the size and frequency of the task at hand.

[0] https://github.com/microsoft/vscode-extension-samples/blob/m...

[taeric]

I don't think that is quite right, actually. There are facilities in emacs to do async things. Such that you can make a similar latency trade-off.

I agree the difference is emacs is done such that it is all exposed to all developers. There are no special parts, as it were. Such that a hello world looks like (defun my-ext () (message "hello, world")). If binding this to a key, you simply need to add (interactive) after the argument list.

Obviously, things ramp up quickly, but the point is it isn't some special framework to make extensions. It is just a function.

[TeMPOraL]

Importantly to my original point, if I didn't like the message your little function printed, and you didn't design your "extension" to be extensible (e.g. by putting "hello world" in a defvar or defcustom), I can just... redefine your function - and everyone else using it will pick my new definition. Or I could defadvice it to modify its behavior without changing its definition.

As you say, Emacs has no special framework for extensions - it's all just functions and variables, plus a bunch of higher-level concepts (e.g. minor and major modes, customize, autoloads) to pick and choose from.

[meetups323]

The Emacs approach is a bit more closely followed by Atom, where extensions have full access to the window, are responsible for their own UI elements, and many "core" features are actually just extensions. Atom faced many of the same difficulties with this as Emacs -- when absolutely everything in the interface is "public", it becomes very hard to make changes without breaking userspace. But yes, it does allow for a much more diverse extension ecosystem.

Tradeoffs all the way down :) If we didn't have them we wouldn't be engineers...

[taeric]

The problem with Atom is that they didn't set a stable foundation for where to expose everything. That is, the window that they expose is itself under active development, if I understand correctly.

This is an odd shift of the word "stable" in software. For a long time, folks took stable to mean simply "doesn't crash." But, it also needs to mean "remains unchanged" if you want to use it as a foundation of other work.

Of course, I say that, and have to ack that the web itself has proven a major exception to this supposed rule. Nothing has been stable in that entire landscape, but it has continued to grow at an astonishing pace.