windows support about firenvim HOT 9 CLOSED

If there is something Nvim core can add which would eliminate the need for the rust component, that would very much be something we would try to support.

from firenvim.

I see, the rust binary can probably be replaced with a plugin then, thanks :)

from firenvim.

I haven't tried to run firenvim in windows yet but it should work, it just requires adding a few keys to the registry. I plan on adding this functionality to the rust component.

The rust component is just a really simple program which translates firefox's native messaging protocol into "raw" messages. Removing it would require adding a way for neovim to automatically detect the messages it's receiving are using firefox's protocol (this could probably be achieved by checking whether the two arguments neovim was started with are the ones Firefox gives to programs it starts) but I'm not sure this belongs in neovim (although I'll admit I'd love to have less code to maintain :p). Is there any support on neovim's side to specify "preprocessing" actions that would be applied to messages received on stdin?

Sorry this repo hasn't been updated in a while, I've been very busy. I do plan on getting back to this and making it actually usable on all three platforms and all webextension-supporting browsers.

from firenvim.

Is there any support on neovim's side to specify "preprocessing" actions that would be applied to messages received on stdin?

stdin can be processed arbitrarily by starting Nvim with --embed --headless and calling stdioopen() to create a channel on stdin/stdout. See :help stdioopen()

from firenvim.

I have added proper windows support to the native binary, built it and uploaded it to the releases pages (this is temporary - I still plan on turning it into a plugin that wouldn't require a native executable).

@justinmk I've been wondering, is it possible to open ports in vimscript/lua? Currently the main problem with firenvim is latency (up to 10ms to send a message and get an answer!). This happens because messages go through several layers of IPC. Thus I believe that the optimal architecture would be to have firenvim talk with neovim through a websocket, without going through a remote plugin. I can write the websocket code myself/steal it from somewhere but I need to have nvim listen on a port to do that.

from firenvim.

is it possible to open ports in vimscript/lua?

@glacambre serverstart() starts a msgpack-RPC server. And Nvim always has at least one of these running at startup (v:servername).

If you don't want to use msgpack-rpc we could maybe add that as a feature-request. But it's probably a good idea to use msgpack-rpc, since one needs some sort of protocol.

from firenvim.

@justinmk I do want to use msgpack-rpc but over websockets, which have their own protocol. So this is what sending a message would look like:

Browser sends a msgpack-rpc message over a websocket
                                      |
                                      v
Lua plugin running inside neovim receives the request on the socket it opened in neovim,
translates the websocket-msgpack-rpc message into a regular msgpack-rpc message and writes
it to a neovim channel
                                      |
                                      v
neovim processes the msgpack-rpc message and replies on the same channel
                                      |
                                      v
Lua plugin receives the answer, wraps in into a websocket request and sends it on its TCP
socket
                                      |
                                      v
Browser receives the message and does whatever it wants with it

That's why I would need to be able to open "normal" TCP sockets.

from firenvim.

@glacambre would you mind creating a feature-request?

from firenvim.

I'm going to close this since Firenvim now works on windows. If you want to follow progress on removing the native binary, please subscribe to #22.

from firenvim.