Closed cpkio closed 3 years ago
Thanks @cpkio. It's not clear to me why that is the case. Could you run
local p = vim.loop.new_pipe()
local ret = p:bind("testing.pipe")
print(ret)
and investigate into what happens? It's not clear to me why that is not creating the pipe.
Your code does E5113: Error while calling lua chunk: r:\test.lua:1: bad argument #1 to 'new_pipe' (boolean expected, got no value)
This will work (windows pipes have special names):
local p = vim.loop.new_pipe(false)
local ret = p:bind([[\\.\pipe\neovimpipe]])
print(ret)
This code successfully connects to pipe server testpipe
and sends a message.
local p = vim.loop.new_pipe(true)
p:connect([[\\.\pipe\testpipe]])
p:write("hello")
print(p:getpeername())
results
\\?\pipe\testpipe
I see, I did not know of the special windows pipe filesystem. I updated the master branch, could you do some more debugging? Thanks a lot for your help, I've been busy lately and slow, but I want to get this supported!
Running the same sample code from top post results in ...a\nvim-data\site\pack\user\start\nvim-fzf\lua\fzf.lua:31: attempt to index local 'file' (a nil value) function: builtin#18 ...a\nvim-data\site\pack\user\start\nvim-fzf\lua\fzf.lua:31: attempt to index local 'file' (a nil value)
, which means
https://github.com/vijaymarupudi/nvim-fzf/blob/0f1f33a2991d47f19b7ecc39a560544e05ddca20/lua/fzf.lua#L31 or https://github.com/vijaymarupudi/nvim-fzf/blob/0f1f33a2991d47f19b7ecc39a560544e05ddca20/lua/fzf.lua#L143 is nil
.
I'll try to get this working for myself.
Change fzf.lua:82 to return ([[\\.\pipe\%s]]):format(random_filename)
, you missed the leading slash so the pipe didnt create. With this fix, FZF runs, but has no input, so there's something wrong on the way of passing {"choice 1", "choice 2"}
to the pipe.
I dont know if you should try to keep both Linux and Windows functionality in one file.
local uv = vim.loop
pipein = uv.new_pipe(false)
pipeout = uv.new_pipe(false)
local pipeinname = [[\\.\pipe\pipein]]
local pipeoutname = [[\\.\pipe\pipeout]]
pipeout:bind(pipeoutname)
pipein:bind(pipeinname)
pipeout:listen(16, function()
local client = uv.new_pipe(false)
pipeout:accept(client)
client:write("hello!\nworld!\ntest data!")
client:close()
end)
pipein:listen(16, function()
local client = uv.new_pipe(false)
local callback = function(err, chunk)
print(chunk) -- let's see what we have got from fzf
client:close()
end
pipein:accept(client)
client:read_start(callback)
end)
If this code is run from Nvim, then command line fzf < \\.\pipe\pipeout > \\.\pipe\pipein
will get 3 lines from Nvim and pass the selected string back to \\.\pipe\pipein
. This has been tested. I dont exactly understand yet how coroutines and uv asyncs work, hope you could build this in somehow.
I think fd = uv.fileno(pipe_handle)
does not work:
pipeout:listen(16, function()
local client = uv.new_pipe(false)
pipeout:accept(client)
local fd = uv.fileno(client)
uv.fs_write(fd, "string\ndata\nhello\n", -1)
uv.fs_close(fd)
end)
This will result in callback error.
That example is great, thank you! I'll be working on this in the next week, fingers crossed it'll fix the issue!
A question about file redirection, ideally I don't want to output fzf results to a pipe, but a file. Is output redirection, like ls > file.txt
supported in cmd.exe?
Yes, you can redirect to a file easily. Still I thinks for Windows it should be another pipe, I suspect it would be faster.
For now I'm going to use a file because I think it'll unlikely the user will select enough data for the performance to matter. Will do optimizations later if necessary.
Could you test the https://github.com/vijaymarupudi/nvim-fzf/tree/core-refactor branch please?
The example file seems to be working as expected! print(result[1])
prints to hidden, and is visible only in :messages
.
Great! Not sure why it's hidden, but this is great news! Next thing would be to test the action API, and then that should be it!
I'm going to consider this solved, since I just pushed the patch to master. Please open a new issue for the action API when you come around to using it. It currently uses a named socket on Unix, so I assume with some minor changes we can get it to work on Windows easily!
Stopped by to thank you for your work and say how much I appreciate it. I've got tired of supporting my own fork of fzf.vim
for Windows and I'm very grateful to you because you've built this plugin and I can use it out of the box in Windows. fzf-lua
author's decision to drop Windows compatibility is unfortunate.
You're welcome, thank you for your contributions that helped make it happen!
Running
luafile %
example fileproduces this error:
E5113: Error while calling lua chunk: r:\1.lua:8: ...a\nvim-data\site\pack\dmitriy\start\nvim-fzf\lua\fzf.lua:198: ...a\nvim-data\site\pack\dmitriy\start\nvim-fzf\lua\fzf.lua:22: bad argument #1 to 'func' (number expected, got nil)
[^1][^1]: BTW, this https://github.com/vijaymarupudi/nvim-fzf/blob/679714e140ab9b5f26731c300ecbc9108d2c9fe1/lua/fzf.lua#L111 returns
nil
(LibUV says itReturns: 0 or fail
).