Hacker News new | ask | show | jobs
by AndreasBackx 949 days ago
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.
4 comments

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.

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

No one understands CMake files

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.

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

Could we define a common specification for how those brokers should interact with other objects, and call it CORBA?
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.

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