vijaymarupudi / nvim-fzf

A Lua API for using fzf in neovim.
MIT License
340 stars 13 forks source link

Running a sample code produces error in Windows #37

Closed cpkio closed 3 years ago

cpkio commented 3 years ago

Running luafile % example file

local fzf = require('fzf')

coroutine.wrap(function()
  local result = fzf.fzf({"choice 1", "choice 2"})
  if result then
    print(result[1])
  end
end)()

produces 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 it Returns: 0 or fail).

vijaymarupudi commented 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.

cpkio commented 3 years ago

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)
cpkio commented 3 years ago

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
vijaymarupudi commented 3 years ago

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!

cpkio commented 3 years ago

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.

cpkio commented 3 years ago

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.

cpkio commented 3 years ago

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.

vijaymarupudi commented 3 years ago

That example is great, thank you! I'll be working on this in the next week, fingers crossed it'll fix the issue!

vijaymarupudi commented 3 years ago

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?

cpkio commented 3 years ago

Yes, you can redirect to a file easily. Still I thinks for Windows it should be another pipe, I suspect it would be faster.

vijaymarupudi commented 3 years ago

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.

vijaymarupudi commented 3 years ago

Could you test the https://github.com/vijaymarupudi/nvim-fzf/tree/core-refactor branch please?

cpkio commented 3 years ago

The example file seems to be working as expected! print(result[1]) prints to hidden, and is visible only in :messages.

vijaymarupudi commented 3 years ago

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!

vijaymarupudi commented 3 years ago

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!

cpkio commented 2 years ago

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.

vijaymarupudi commented 1 year ago

You're welcome, thank you for your contributions that helped make it happen!