[TeMPOraL]

> access to token information

This is perhaps the core difference between VS Code and Emacs (which a lot of people believe is being superseded by VS Code as the "extensible editor") - in Emacs, there is no such thing as limiting access to information. Outside of things that get hidden accidentally[0], any bit of elisp code can access everything.

It's not just a practical difference, but also a philosophical one: Emacs plugins are not designed to expose a narrow API, because it's impossible to enforce anyway. There's a structure to it, so nothing prevents one from creating good abstractions - those abstractions just have to be designed with extensibility and interoperability in mind[1], because the users (including other package developers) always have an option to just hook into, advise, override or replace any piece of code in your package.

Performance-wise, the impact of it varies. On the one hand, this level of flexibility prevents Emacs from making important breaking changes[2]. On the other hand, nothing ever has to wait for a better API design - if there's a way to make a feature faster by hooking to a dependency's internal, people will do just that, and keep doing that until the API blesses the use case.

--

[0] - Like state the C core doesn't expose, or some implicit state shared by a bunch of closures - though you can get at the latter if you override whatever is hiding the state.

[1] - E.g. by offering hooks as a blessed, well-defined and stable way to interact with internals to cover 90% of interoperability needs.

[2] - Like doing proper multithreading, or replacing Emacs Lisp with a more polished Lisp - though myself I feel ELisp is good enough as a language.

[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]

I am also in the camp that thinks elisp is fine.