lervag
`fzf-lua` TOC integration does not work
Description
Using the example mentioned in the documentation, namely
vim.keymap.set("n", "<localleader>lt", function()
return require("vimtex.fzf-lua").run()
end)
when I enter <localleader>lt, a black screen pops up for a split second and then disappears. Vimtex and fzf-lua are up-to-date.
Steps to reproduce
- place
into your config.vim.keymap.set("n", "<localleader>lt", function() return require("vimtex.fzf-lua").run() end) nvim minimal.tex- run
<localleader>lt
Expected behavior
The expected behaviour is that the fzf-lua TOC viewer window opens and functions properly.
Actual behavior
When the following steps are run, I observe that a black window momentarily appears on the screens, and then disappears.
Do you use a latexmkrc file?
no
VimtexInfo
System info:
OS: macOS 15.2 (24C101)
LaTeX version: pdfTeX 3.141592653-2.6-1.40.27 (TeX Live 2025)
Vim version: NVIM v0.11.2
Has clientserver: true
Servername: /var/folders/dy/vxsx3_md4vd7ngkn6cs70ggw0000gn/T/nvim.jayansunil/5HYKgL/nvim.54031.0
$PATH:
- /Applications/Wireshark.app/Contents/MacOS
- /Applications/iTerm.app/Contents/Resources/utilities
- /Applications/quarto/bin
- /Library/Apple/usr/bin
- /Library/Frameworks/Python.framework/Versions/3.12/bin
- /Library/Frameworks/Python.framework/Versions/3.13/bin
- /Library/TeX/texbin
- /System/Cryptexes/App/usr/bin
- /Users/jayansunil/.atuin/bin
- /Users/jayansunil/.cargo/bin
- /Users/jayansunil/.fzf/bin
- /Users/jayansunil/.local/bin
- /Users/jayansunil/.local/share/nvim/mason/bin
- /Users/jayansunil/.zvm/bin
- /Users/jayansunil/.zvm/self/
- /Users/jayansunil/Library/Application Support/org.IntelliShell.Intelli-Shell/bin
- /Users/jayansunil/miniconda3/bin
- /bin
- /opt/X11/bin
- /opt/homebrew/bin
- /opt/homebrew/sbin
- /opt/local/bin
- /opt/local/sbin
- /sbin
- /usr/bin
- /usr/local/bin
- /usr/local/sbin
- /usr/sbin
- /var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin
- /var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin
- /var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin
- ~/.local/bin
VimTeX project: main
base: main.tex
root: /Users/jayansunil/Documents/MUNs/BBIMUN/position_paper/src
tex: /Users/jayansunil/Documents/MUNs/BBIMUN/position_paper/src/main.tex
main parser: current file verified
document class: article
document class options: 11pt=true a4paper=true oneside=true
packages: biblatex csvsimple datetime enumitem fancyhdr float fontspec geometry graphicx hyperref inputenc lettrine libertine marginnote mdframed multicol sectsty titlesec
compiler: generic
options:
-Z
search-path=/usr/local/texlive/2025/texmf-dist/tex/latex/biblatex
out_dir: ../build/main/
viewer: Zathura
xwin id: 0
qf method: LaTeX logfile
Using the example mentioned in the documentation, namely
vim.keymap.set("n", "
lt", function() return require("vimtex.fzf-lua").run() end) when I enter
<localleader>lt, a black screen pops up for a split second and then disappears. Vimtex and fzf-lua are up-to-date.
This is very likely caused by your own configuration. The same mapping with a minimal configuration works perfectly well.
Steps to reproduce
place
vim.keymap.set("n", "<localleader>lt", function() return require("vimtex.fzf-lua").run() end)into your config.
nvim minimal.texrun
<localleader>lt
Can you create a minimal configuration that still reproduces your problem? You can start with something like this:
local fzf_lua_path = "./fzf-lua"
if not vim.uv.fs_stat(fzf_lua_path) then
vim.fn.system {
"git",
"clone",
"--filter=blob:none",
"https://github.com/ibhagwan/fzf-lua/",
fzf_lua_path,
}
end
vim.opt.rtp:prepend(fzf_lua_path)
vim.opt.runtimepath:prepend "/PATH/TO/VIMTEX"
vim.opt.runtimepath:append "/PATH/TO/VIMTEX/after"
vim.cmd [[filetype plugin indent on]]
vim.keymap.set("n", "q", "<cmd>qall!<cr>")
vim.keymap.set("n", "<localleader>lt", function()
return require("vimtex.fzf-lua").run()
end)
vim.g.vimtex_cache_persistent = false
Notice, though, that you also need to have fzf itself available and on your PATH.
VimtexInfo
From your VimtexInfo I can see you are using the generic compiler. That's not very common, so out of curiousity, how does that work for you?
Can you create a minimal configuration that still reproduces your problem? You can start with something like this:
Sure, I'll update here when im done
From your VimtexInfo I can see you are using the generic compiler. That's not very common, so out of curiousity, how does that work for you?
I use the generic compiler with tectonic (tectonic -X watch), because i really like the build system of tectonic. I also have a key bind to switch to LatexMk when necessary
From your VimtexInfo I can see you are using the generic compiler. That's not very common, so out of curiousity, how does that work for you?
I use the generic compiler with tectonic (
tectonic -X watch), because i really like the build system of tectonic. I also have a key bind to switch to LatexMk when necessary
Ah, cool. Thanks for sharing!
After a bit more digging, I decided to manually put the code for the fzf-lua integration into my keymap binding. I found that removing the following line fixed the issue, albeit the picker doesn't look as pretty as it should.
fzf.fzf_exec(fzf_entries, {
-- Removed fzf_opts = fzf_options,
actions = {
default = function(selection, o)
local s = vim.tbl_map(function(t)
return vim.split(t, "####")[1]
end, selection)
fzf.actions.file_edit(s, o)
end,
},
})
After even more digging, it seems like ["--with-nth"] = "{2} {3}", is causing the issue, as without it, the picker runs fine
I have found the problem: the fzf version that I was running did not support the ["--with-nth"] = "{2} {3}" syntax, causing it to error. I suggest adding a section regarding minimum supported fzf version (0.60.2), to prevent things like this in the future
Ah, right. Notice, though, that the --with-nth option for fzf have been supported for more that 5 years now, but I notice we are using the template option that came in 0.60.2 for the fzf-lua version. I'll add it to the docs.
I assume this issue is resolved, then?