Hacker News Reader

Comment by AndreasBackx | Hacker News Reader

I wonder whether it's achievable to have a plugin system similar to how web extensions work where you could write a plugin and have it work across different editors. I see how getting people to move to this editor might depend on people moving over once a sufficient amount of their current editor's features are supported, some of which might be contributed by extensions.

View on HN

Perhaps using WASM via something like https://extism.org/. That would also open it up to building plugins in multiple languages.

Tangential to this I've wondered if it's possible or advisable to have a utility to port VS Code plugins to a plugin that's compatible with the JetBrains IDEs.

> Perhaps using WASM via something like https://extism.org/. That would also open it up to building plugins in multiple languages.

https://github.com/lapce/lapce already says,

> Plugins can be written in programming languages that can compile to the WASI format (C, Rust, AssemblyScript)

so it sounds like they did that?

So an interface like LSP but for plugins… very interesting idea!

Text manipulation operations are fairly simple to define and can probably be abstracted away into some generic API. Then writing generic text manipulation plugins should be very doable.

The complexity comes with project management, multiple files, build actions, etc. But you could define language specific sub-interfaces and the plugins would implement them. So a C++ plugin would understand CMake files for example.

The complexity comes with interaction in general. Writing plugins on their own is simple. And defining a good API for most common use cases is also not hard today, as we have enough experience now. But the hard part will be defining an independent Interface which will work everywhere on a satisfying level.

I mean that's basically the biggest selling-point of plugin-systems today. Not that you can write your own functions to do something, but how well you can integrate it into the interface and deliver your own interface to enhance the app. And another part would be safe interaction with other plugins, and necessary package-managment.

>So a C++ plugin would understand CMake files for example.

No one understands CMake files

There seems to be some trend, to outsource plugins into their separate processes, so you can write them in your preferred language. So APIs are already being established here and there. All we probably need is someone carving out a standard from them, with room for editor-specific enhancement, and then convince the projects to support this.

Maybe the neovim-people could get together with other projects, start some group, project, whatever to discuss this further? Of maybe something like this already exists?

Maybe we could invent a standard technology for defining interfaces between software pieces. We could call it Interface Definition Language (IDL for short). And then we could have something that brokers requests to those objects to facilitate intercommunication. We could call that an ORB! Finally a good idea!

oh man, we can then build it into the OS and give it a recognizeable name like Component Object Model!

Could we define a common specification for how those brokers should interact with other objects, and call it CORBA?

Yes, why not! But I guess that's too complex, we'd need a simple object access protocol!

OMG, why are we talking about ancient uncool technology?

Jokes aside, there are so many cool standards for doing stuff it's a shame we seem to reinvent the wheel over and over again.

I have an even simpler idea. We can have some kind of protocol header that specifies the size and shape of the structures and functions that can be called using a binary-level interface. Then we can just provide the implementation as machine code where the header maps each callable function to its respective code block. To "return" values, the callables can just push their results onto a "stack" at a known location and return control to the caller.

The bonus is this should be really fast and it doesn't even require any codec or message copying.

Reply on news.ycombinator.com