OSError: EOF when trying to run example code on Windows #505
Comments
|
The neovim is already running? I think it is not running. |
|
I thought the purpose of this code was to launch neovim as a child process and attach to that. If I launch neovim (externally, just by running it) and then run the code I get the same error. |
|
The backslash escape is needed in single quotes? |
|
Seems like it... I'm fairly sure it is finding |
|
Hm. You should enable log. |
|
Reproduced it on neovim 0.7 Windows version. It works on older neovim(0.5) or Linux neovim. Unfortunately, pynvim is not maintained well. neovim maintainers want to use Lua language instead. Note: if_python3 works well. |
|
Ah, thanks for that. I'll look into getting something else working. |
|
neovim 0.4.4 was the latest version I was able to pynvim to work well with. For context, I'm on windows trying to use the ActualVim plugin on Sublime Text 4. |
|
Any updates on this? Tried it using Neovim 0.9.0 but still doesnt work.. |
|
Since CI (github actions) is online now, Windows CI jobs are showing similar failures (python 3.10, 3.11) : |
Problem: An EOF error happens when creating a subprocess Nvim instance
on Windows. All CI tests are failing, and `attach('child', ...)` cannot
be run
Solution: Ignore pipe_connection_lost error, and do not close the
asyncio event loop. Since embedded nvim only expects to use stdin and
stdout only as a msgpack-RPC channel, it's fine to ignore broken pipes
on the stderr.
Fixes neovim#505
Problem: An EOF error happens when creating a subprocess Nvim instance
on Windows. All CI tests are failing, and `attach('child', ...)` cannot
be run.
Solution: Ignore pipe_connection_lost error, and do not close the
asyncio event loop. Since embedded nvim only expects to use stdin and
stdout only as a msgpack-RPC channel, it's fine to ignore broken pipes
on the stderr.
Fixes neovim#505
Problem: An EOF error happens when creating a subprocess Nvim instance
on Windows. All CI tests are failing, and `attach('child', ...)` cannot
be run.
Solution: Ignore pipe_connection_lost error, and do not close the
asyncio event loop. Since embedded nvim only expects to use stdin and
stdout only as a msgpack-RPC channel, it's fine to ignore broken pipes
on the stderr.
Fixes neovim#505
|
neovim/neovim@ |
Problem: An EOF error happens when creating a subprocess Nvim instance
on Windows. All CI tests are failing, and `attach('child', ...)` cannot
be run.
Solution: Ignore pipe_connection_lost error, and do not close the
asyncio event loop. Since embedded nvim only expects to use stdin and
stdout only as a msgpack-RPC channel, it's fine to ignore broken pipes
on the stderr.
Fixes neovim#505
Problem: An EOF error happens when creating a subprocess Nvim instance
on Windows. All CI tests are failing, and `attach('child', ...)` cannot
be run.
Solution: Ignore pipe_connection_lost error, and do not close the
asyncio event loop. Since embedded nvim only expects to use stdin and
stdout only as a msgpack-RPC channel, it's fine to ignore broken pipes
on the stderr.
Fixes neovim#505
Problem: An EOF error happens when creating a subprocess Nvim instance
on Windows. All CI tests are failing, and `attach('child', ...)` cannot
be run.
Solution: Ignore pipe_connection_lost error, and do not close the
asyncio event loop. Since embedded nvim only expects to use stdin and
stdout only as a msgpack-RPC channel, it's fine to ignore broken pipes
on the stderr.
Fixes neovim#505
Problem: An EOF error happens when creating a subprocess Nvim instance
on Windows. All CI tests are failing, and `attach('child', ...)` cannot
be run.
Solution: Ignore pipe_connection_lost error, and do not close the
asyncio event loop. Since embedded nvim only expects to use stdin and
stdout only as a msgpack-RPC channel, it's fine to ignore broken pipes
on the stderr.
Fixes neovim#505
I'm trying to run the example code on the main page of the README, namely:
But I get an error instead:
Running the same thing from a script gives a bit more info, but I think it's irrelevant:
Any pointers? I've also tried connecting using a socket but that also behaves weirdly on Windows.
The text was updated successfully, but these errors were encountered: