helix icon indicating copy to clipboard operation
helix copied to clipboard

RPC-based Plugin System

Open kirawi opened this issue 4 years ago • 5 comments

In addition to #122, it would be nice to make it possible to implement plugins through an RPC interface like in Neovim. One major benefit from this is that it would make it easier to use scripting languages like Python as the compiler wouldn't need to be compiled down to WebAssembly. Another potential use is that external programs or plugins (not sandboxed) can directly work with Helix. If we accept this as a feature we'd like for Helix to have, I think that it would be best for it to be implemented as a WebAssembly plugin.

See #387 for a real-world use case.

kirawi avatar Nov 06 '21 23:11 kirawi

It looks like LSP architecture but for interacting with editor instead of per language. :)

wingyplus avatar Nov 28 '21 06:11 wingyplus

If it's okay, I'll add my real-world use case that I have with Neovim.

I switch from light/dark appearance in macOS depending on a few factors [1]. I've written a little binary [2] that runs and listens for appearance change events and then tells Neovim [3] to change the theme to the appropriate light/dark one.

[1] macOS default change based on sunrise/sunset, but also just depending on the weather and lighting where ever I currently am. [2] https://github.com/jesse-c/AppearanceNotifier [2] https://github.com/mhinz/neovim-remote

jesse-c avatar Feb 07 '22 22:02 jesse-c

Can we just implement a dead simple pipe based interface which will be trivial to maintain over the long term even when a more complex plugin system gets implemented? I'm thinking something like a pipe file which is read line-wise as a command. It would go through the same code flow as manually entering a command, but the actual command would just be sourced from the pipe. helix is already dependent upon tokio already has an API for this, and it could just be tacted onto the application event loop.

Something like this seems like it would be easy to maintain. It could be kept in even after a more robust plugin system has been implemented because it's low cost. For some tasks, this might even be preferable to writing a full plugin as it is easily automated by end users. You wouldn't have to understand the inner working of helix's plugin system to automate a simple task. You just have to understand the commands available.

Something like this would reload the theme when it is written to which will improve designer experience:

while :; do
  inotifywait -e modify ~/.config/helix/themes/mytheme.toml
  find "${XDG_RUNTIME_DIR-/tmp}/helix/pipes" -mindepth 1 \
  | while read hxpipe; do
    echo 'theme mytheme' > "$hxpipe"
  done
done

gcoakes avatar Feb 28 '22 04:02 gcoakes

Just to chime in gRPC might be a good option. It can be run over various transports e.g. pipes/sockets or http. It also has client-server generators for multiple languages including rust.

nathaniel-brough avatar Sep 26 '22 02:09 nathaniel-brough

Shameless plug, but my crate ipc-rpc seems like it might actually be a pretty good fit here. Built in serde support, and helix already uses tokio. Plus ipc-rpc is multiplatform.

Xaeroxe avatar Oct 17 '22 03:10 Xaeroxe

Closing, see https://github.com/helix-editor/helix/discussions/3806#discussioncomment-4723781

pascalkuthe avatar Jan 19 '23 07:01 pascalkuthe