Previewer (builtin/cat/bat) errors

[benyn]

Info

• Operating System: macOS Ventura 13.2.1 (22D68)
• Shell: zsh
• Terminal: Apple Terminal / VimR
• nvim --version: v0.8.3 (Terminal) / v0.8.2 (VimR)
• fzf --version: 0.38.0
• The issue is reproducible with mini.sh

fzf-lua configuration

require('fzf-lua').setup({
  winopts = {
    preview = {
      default = "bat",
    },
  },
  grep = {
    cmd = "rg",
    file_icons = false,
    color_icons = false,
    git_icons = false,
  },
})

Description

I tested FzfLua after seeing @ibhagwan 's Reddit post, it worked well, so I added it to my Neovim setup. For some reason, none of the three previewers work, neither in a GUI (VimR) nor in a terminal (Apple Terminal).

The builtin previewer works well in Terminal, but gives a blank screen in VimR.

cat gives the following error message, both in Terminal and VimR:

cat: illegal option -- -
usage: cat [-belnstuv] [file ...]

bat gives the following error message, both in Terminal and VimR:

[bat error]: invalid digit found in string

I've only tried live_grep, live_grep_native, and help_tags. live_grep works in Terminal but fails to populate the list in VimR, hence my grep settings. (I got the idea from live_grep_native source code.) Not sure if these are enough details to identify the cause. Happy to provide more details!

[ibhagwan]

cat: illegal option -- -

I'll fix this one, nobody really uses cat so it didn't come up but the default cat options are for GNU cat which isn't the case on Mac, in the meantime can you try setting the below and let me know if it works?

require("fzf-lua").setup({
  previewers = {
    cat = { cmd   = "cat", args  = "" }
  }
})

As for the bat error can you please try :FzfLua files previewer=bat_async and lmk if this works?

If so, you can set it in the meantime in your setup until we figure out why the regular bat (native) doesn't work:

require('fzf-lua').setup({
  winopts = {
    preview = {
      default = "bat_async",
    },
  },
})

[ibhagwan]

Can you please update to the latest commit da1881a and test default cat again, just tested it on a Mac and it worked.

Awaiting further responses from you so we can fix bat and the builtin previewer on VimR

[ibhagwan]

Further investigation regarding VimR shows an issue with the internal neovim build packaged within VimR, fzf-lua is dependent on being able to run neovim --headless --cmd with lua commands (in order to have process separation), this seems to segfault with VimR, you can try the below yourself:

You can find out the exact path by running :lua print(vim.v.progpath) inside VimR

❯ '</path/to/>/VimR.app/Contents/Resources/NvimView_NvimView.bundle/Contents/Resources/NvimServer' -n --headless --cmd 'lua print("test")'
zsh: segmentation fault   -n --headless --cmd 'lua print("test")

Vs a standard build:

❯ nvim -n --headless --cmd 'lua print("test\n"); os.exit(0)'
test

I opened an issue upstream qvacua/vimr#1001, hopefully it gets fixed fast.

Edit: apparently it worked with VimR 0.7 but stopped with 0.8, see qvacua/vimr#972, qvacua/vimr#984, neogit users also facing similar issue qvacua/vimr#993, the issues do seem unanswered so I’m not sure how fast this is going to be addressed…

I'm assuming the latest commit fixes the issue with the cat previewer, that leaves us with just one issue, bat previewer which isn't working:

• Can you confirm if bat_async works for you (in terminal neovim run :FzfLua files previewer=bat_async)?
• Can you run :FzfLua files previewer=bat debug=true, press F3 once so we can see the wrapped lines of the debug output and post the contents (or screenshot) of the preview window debug data?

[benyn]

Thanks for a super quick response & update! Yeah, cat now works fine in Terminal, and shows a blank screen in VimR.

And as to VimR, I get the same zsh: segmentation fault error message. Yeah, many VimR issues seem go unanswered, so I'm also not sure how fast this will get addressed, but thanks for opening the issue.

Okay, to the last remaining issue. bat_async do work! Yeah, I can get going with that first. Just curious, is it supposed to be faster or slower than the regular bat? And here's the debug message I got for bat.

[DEBUG] debug = true
[DEBUG] function ID = 3
[DEBUG] fzf_lua_server = /var/folders/ps/z37vy3b970q22dph4z8zf11c0000gn/T/nvim._____/EatHy0/nvim.48545.1
[DEBUG] argv[1] = /opt/homebrew/Cellar/neovim/0.8.3/bin/nvim
[DEBUG] argv[2] = -n
[DEBUG] argv[3] = --headless
[DEBUG] argv[4] = --clean
[DEBUG] argv[5] = --cmd
[DEBUG] argv[6] = lua loadfile([[/Users/_____/.local/share/nvim/lazy/fzf-lua/lua/fzf-lua/shell_helper.lua]])().rpc_nvim_exec_lua({fzf_lua_server=[[/var/folders/ps/z37vy3b970q22dph4z8zf11c0000gn/T/nvim._____/EatHy0/nvim.48545.1]], fnc_id=3 , debug=true})
[DEBUG] argv[7] = --
[DEBUG] argv[8] = [DEBUG]: fd --color=never --type f --hidden --follow --exclude .git
[DEBUG] arg[1] = [DEBUG]: fd --color=never --type f --hidden --follow --exclude .git
[bat error]: '[DEBUG]': No such file or directory (os error 2)

And I'm not sure which file or directory the last error message is referring to, but fzf_lua_server (nvim.48545.1) do exist in my file system.

[ibhagwan]

Okay, to the last remaining issue. bat_async do work! Yeah, I can get going with that first. Just curious, is it supposed to be faster or slower than the regular bat?

No big difference TBH, with bat, fzf spawns the bat which then calls neovim to get the filename (stripped of icons, line, col, text), with bat_async fzf calls neovim which returns the bat output to stdout via a call to libuv, both are super fast and no big difference, in fact it used to be the default until not long ago and I changed it, might go back to async being the default as it’s less error prone to shell escaping woes (which is probably what’s happening here).

And I'm not sure which file or directory the last error message is referring to

That’s because you’re trying to preview the debug mode line :)

Would you be able to screen shot again while the cursor is on a file line (not the debug line)?

[benyn]

I just realized that the preview works for the files command. But I still get the same error message with live_grep. Debug messages for live_grep:

[DEBUG] debua = true
[DEBUG] function ID = 3
[DEBUG] ff_lua_server = /var/folders/ps/237vy3b970q22dph4z8zf11c0000gn/T/nvim._____/ru37JI/nvim.51532.1
[DEBUG] argv[1] = /opt/homebrew/Cellar/neovim/0.8.3/bin/nvim
[DEBUG] argv[2] = -n
[DEBUG] argv[3] = --headless
[DEBUG] argv[4] = --clean
[DEBUG] argv[5] = --cmd
[DEBUG] argv[6] = lua loadfile([[/Users/_____/.local/share/nvim/lazy/fzf-lua/lua/fzf-lua/shell_helper.lua]])().rpc_nvim_exec_lua({fzf_lua_server=[[/var/folders/ps/z37vy3b970q22dph4z82f11c0000gn/T/nvim._____/ru37JI/nvim.51532.1]], fnc_id=3 , debug=true})
[DEBUG] argv[7] = --
[DEBUG] argv[8] = lazy-lock.json
[DEBUG] arg[1] = lazy-lock.json
[bat error]: invalid digit found in string

[ibhagwan]

I just realized that the preview works for the files command. But I still get the same error message with live_grep. Debug messages for live_grep

As I suspect it’s probably just shell escaping woes due to the matching text which also gets sent to the bat command and confuses the shell, can you post the full text in the selected line from live grep where it fails (from the main fzf window, not the preview)?

I’m suspecting some special characters in there the shell doesn’t like, I will test myself using text from lazy-lock.json which I see was used here.

[benyn]

I'm not sure if the content of the file matters here. I just created a simple test.txt that has 5 characters hello, and even that gives [bat error]: invalid digit found in string. 😞

[ibhagwan]

I'm not sure if the content of the file matters here. I just created a simple test.txt that has 5 characters hello, and even that gives [bat error]: invalid digit found in string. 😞

Maybe it’s your home folder or system path that fails, can you cd /etc and try there, if that works can you post the output of pwd within a failed folder?

I’m going to restore bat_async as default anyways once I implement an improvement for it later today.

[ibhagwan]

2d4e3af - this commit should "solve" the bat issues, I wrote solve in quotes as this changes the default back to bat_async (with slight improvement regarding process spawn).

It's up to you if you want to continue troubleshooting this issue (which I suspect is OS path related), the only difference is that now in order to invoke the bug you'd need to set the previewer to bat_native specifically :FzfLua live_grep previewer=bat_native.

If you're happy with how it works and don't feel inclined to try and figure this out it's ok as I plan to one day phase out the bat_native previewer as it makse no sense to keep maintining both as long as the other is working perfectly.

[benyn]

I just tried in /etc and every single file gives the same error there, too. I'll just close out the issue since I can use the new bat a.k.a. bat_async and it sounds like bat_native will be retired. Thanks again for prompt help!

[SolaWing]

vimr issue can be dirty fixed by change the NvimServer binary to nvim as headleass subprocess.

diff --git a/lua/fzf-lua/libuv.lua b/lua/fzf-lua/libuv.lua
index ba1ba2c..7c5e7db 100644
--- a/lua/fzf-lua/libuv.lua
+++ b/lua/fzf-lua/libuv.lua
@@ -465,7 +465,8 @@ end
 M.wrap_spawn_stdio = function(opts, fn_transform, fn_preprocess)
   assert(opts and type(opts) == "string")
   assert(not fn_transform or type(fn_transform) == "string")
-  local nvim_bin = vim.v.progpath
+  -- local nvim_bin = vim.v.progpath
+  local nvim_bin = "nvim"
   local call_args = opts
   for _, fn in ipairs({ fn_transform, fn_preprocess }) do
     if type(fn) == "string" then
diff --git a/lua/fzf-lua/shell.lua b/lua/fzf-lua/shell.lua
index dce9dc5..db26a2b 100644
--- a/lua/fzf-lua/shell.lua
+++ b/lua/fzf-lua/shell.lua
@@ -60,7 +60,8 @@ function M.raw_async_action(fn, fzf_field_expression, debug)
 
   -- this is for windows WSL and AppImage users, their nvim path isn't just
   -- 'nvim', it can be something else
-  local nvim_bin = vim.v.progpath
+  -- local nvim_bin = vim.v.progpath
+  local nvim_bin = "nvim"
 
   local call_args = ("fzf_lua_server=[[%s]], fnc_id=%d %s"):format(
     vim.g.fzf_lua_server, id, debug and ", debug=true" or "")

[ibhagwan]

vimr issue can be dirty fixed by change the NvimServer binary to nvim as headleass subprocess.

Ty @SolaWing, I thought about it and opted against it, you’re not guaranteed the user has neovim binary installed and even if it is might be some unknown version with other bugs and a hell to troubleshoot, perhaps ok as a hack for someone who really wants it to work.

[benyn]

Thanks for this brilliant idea, @SolaWing ! I just overrode those two functions locally and it works very well. In fact, in my case, it was enough to override raw_async_action only to get the preview fixed, but it's probably safe to override both just in case.

@ibhagwan I agree this is a hack fraught with danger. Hope VimR fixes the issue soon. Thanks for this great plugin! I'm happy that I can use it in both of my environments now. :)

[ibhagwan]

Thanks for this brilliant idea, @SolaWing ! I just overrode those two functions locally and it works very well. In fact, in my case, it was enough to override raw_async_action only to get the preview fixed, but it's probably safe to override both just in case.

@ibhagwan I agree this is a hack fraught with danger. Hope VimR fixes the issue soon. Thanks for this great plugin! I'm happy that I can use it in both of my environments now. :)

That's great @benyn and ty @SolaWing for bringing this to conclusion.

I really dislike users having to use hacks to make things work and this seems imporant to you so I just puhsed a much easier fix (368b998) that you can apply that doesn't require any maintenance on your part.

Set the FZF_LUA_NVIM_BIN enviroment variable to a working terminal neovim binary and you're done!

You can also do it specifically just for neovim by adding this to yor config:

vim.env.FZF_LUA_NVIM_BIN="nvim"

And test to see if it worked with:

:lua print(os.getenv("FZF_LUA_NVIM_BIN"))

[benyn]

That works very well. Thanks for going above and beyond, @ibhagwan !

[benyn]

This might be an off topic question, but for live_grep, is the matching line supposed to be highlighted in preview? Or jump to the matching line when selected? Neither happens, whether I use VimR or Terminal.

[ibhagwan]

This might be an off topic question, but for live_grep, is the matching line supposed to be highlighted in preview? Or jump to the matching line when selected? Neither happens, whether I use VimR or Terminal.

Yes, it should work, I’m pretty sure this is related to the shell escaping stuff that also caused bat to fail on your system with ‘live_grep`, let’s open a new issue and work on it there?

[benyn]

Argh. So that issue is more pervasive. Okay, I'll open a new issue.