Bug: Neovim 0.11 rendering bug

[reybits]

RTFM Checklist

• [x] I have searched exisiting issues / discussions
• [ ] I have read the Wiki including the Advanced section
• [x] I have read man fzf / I am well versed in shell fzf

Operating system

macOS

Shell

zsh

Neovim version (nvim --version)

NVIM v0.11.0

Fzf version (fzf --version)

0.60.3 (brew)

Output of :lua print(os.getenv('FZF_DEFAULT_OPTS'))

--height 75% --layout=reverse --border --no-hscroll --info inline-right

Is the problem reproducible with mini.sh?

• [ ] My issue is reproducible with mini.sh
• [x] My issue IS NOT reproducible with mini.sh
• [ ] I have not tested with mini.sh (not relevant, requires LSP, Windows, etc)

Fzf-lua configuration

require('fzf-lua').setup({
            -- profile
            "hide", -- or "telescope",

            winopts = {
                width = 0.96,
                height = 0.96,
                preview = {
                    layout = "vertical",
                    vertical = "up:70%",
                },
            },
            keymap = {
                builtin = {
                    false,
                    ["<F1>"] = "toggle-help",
                    ["<M-/>"] = "toggle-help",

                    ["<M-S-f>"] = "toggle-fullscreen",

                    ["<M-p>"] = "toggle-preview",
                    ["<M-w>"] = "toggle-preview-wrap",

                    ["<M-c>"] = "toggle-preview-cw",
                    ["<M-S-c>"] = "toggle-preview-ccw",

                    ["<C-d>"] = "preview-page-down",
                    ["<C-u>"] = "preview-page-up",
                },
                fzf = {
                    false,
                    ["alt-a"] = "toggle-all",
                    ["alt-g"] = "first",
                    ["alt-G"] = "last",
                },
            },
            files = {
                hidden = false,
            },
            buffers = {
                prompt = "❯ ",
            },
            keymaps = {
                prompt = "❯ ",
                winopts = { preview = { hidden = true } },
            },
            actions = {
                files = {
                    -- true, -- if set to true, enables default settings.

                    ["enter"] = actions.file_edit_or_qf,
                    ["ctrl-q"] = actions.file_sel_to_qf,
                    ["alt-f"] = actions.toggle_follow,
                    ["alt-h"] = actions.toggle_hidden,
                    ["alt-i"] = actions.toggle_ignore,
                    ["ctrl-s"] = actions.file_split,
                    ["ctrl-v"] = actions.file_vsplit,
                },
            },
            fzf_opts = {
                ["--layout"] = "default",
                ["--history"] = vim.fn.stdpath("data") .. "/fzf-lua-history",
            },
            previewers = {
                builtin = {
                    extensions = {
                        -- neovim terminal only supports `viu` block output
                        ["png"] = { "viu", "-b" },
                        ["jpg"] = { "viu", "-b" },
                        ["gif"] = { "viu", "-b" },
                        ["jpeg"] = { "viu", "-b" },
                        -- ["jpg"] = { "ueberzug" },
                    },
                    -- When using 'ueberzug' we can also control the way images
                    -- fill the preview area with ueberzug's image scaler, set to:
                    --   false (no scaling), "crop", "distort", "fit_contain",
                    --   "contain", "forced_cover", "cover"
                    -- For more details see:
                    -- https://github.com/seebye/ueberzug
                    -- ueberzug_scaler = "cover",
                },
            },

})

Describe the bug / steps to reproduce

Hello! First of all, thank you for the great plugin!

After updating to Neovim 0.11, I consistently experience rendering issues in fzf-lua. However, no such issues occur with FZF in the terminal. Moreover, everything works fine in Neovim 0.10.

[reybits]

Here are several screenshots illustrating the rendering issue.

[ibhagwan]

Here are several screenshots illustrating the rendering issue.

Not sure what I'm looking at here, the first screenshot displays both a double input line as well as something that looks like it's coming from an indent line plugin?

What's wrong with the second screenshot I'm not sure, highlights?

In any event this seems either upstream, double input would be an issue with neovim's term and the highlight issue would be config related (highlights).

Not much I can do here.

[reybits]

On the first screenshot, you can see that the list window has shifted upward, creating a “double” input field.

On the second screenshot, you can see fragments of file names appearing while navigating (notice “luaa,” “luauaua,” etc.).

Am I correct in assuming that the issue is on Neovim 0.11’s side rather than fzf-lua or my configuration?

[phanen]

Yes, I reproduced.

      require('fzf-lua').setup({
        winopts = { preview = { layout = 'vertical', vertical = 'up:70%',  } },
        fzf_opts = { ['--layout'] = 'default' },
      })

Looks very like https://github.com/kevinhwang91/nvim-bqf/blob/ee9c8c842e227462c27b0d8a1eb30845d226f874/lua/bqf/preview/session.lua#L188. But this also happen on nvim <0.11.

I related to the height of fzf term win.

EDIT: https://github.com/neovim/neovim/commit/8df6736ca14d09f87cf0a8486758ac5708819434.

[ibhagwan]

On the first screenshot, you can see that the list window has shifted upward, creating a “double” input field.

On the second screenshot, you can see fragments of file names appearing while navigating (notice “luaa,” “luauaua,” etc.).

I see, ty.

In any event, this is a rendering issue outside of fzf-lua’s control, once fzf-lua starts the terminal process it has no more control over rendering.

@phanen mentioned:

I related to the height of fzf term win.

Maybe your FZF_DEFAULT_OPTS combo with neovim 0.11 are causing this? Can you try running the below command and try again?

:lua vim.env.FZF_DEFAULT_OPTS=nil

[phanen]

No, I erase env before start neovim.

Can be reproduce by mini.sh (with the config above, maybe ensure the fzf term height is small?):

FZF_DEFAULT_OPTS= FZF_DEFAULT_OPTS_FILE= bash scripts/mini.sh

• FzfLua files.
• Maybe you need to continuously press ctrl-j/ctrl-k many times to see this happened.

If disable reflow in neovim then it don't happened: https://github.com/neovim/neovim/commit/8df6736ca14d09f87cf0a8486758ac5708819434.

Either libtermkey bug or fzf. But I if replace --preview with other trivial command then this also don't happen...

[miklhh]

I wonder what causes this issue. I have the exact same rendering problems and it is really bugging me.

[phanen]

@miklhh This can be workaround by disable scrollbar and treesitter-context (which create new float window I think, as mentioned in nvim-bqf's comment).

Or just don't use --layout=default but use --layout=reverse (I don't know why)

Or use ffi to disable relfow on fzf term

[ibhagwan]

If disable reflow in neovim then it don't happened: https://github.com/neovim/neovim/commit/8df6736ca14d09f87cf0a8486758ac5708819434.

Should we open an issue upstream or maybe there is one already?

[phanen]

I didn't find related issue, maybe open one.

[ibhagwan]

I didn't find related issue, maybe open one.

Do you know how can we trigger a reflow easily without fzf-lua? I’d rather open an issue without the dependency being fzf-lua.

[phanen]

Use minimal config with nvim-bqf 😎, then:

• FZF_DEFAULT_OPTS=--bind='ctrl-l:kill-word' nvim
• :grep a | copen<cr>
• zf
• do some ctrl-j/ctrl-k

~Oops, seems I cannot reproduce with this... But I remember I can trigger by bind ctrl-l to another keys. Since bqf use it to trigger redraw.~

A bit flaky.

Ok this can trigger, I will file a issue.

local api = vim.api
local fn = vim.fn
local buf = api.nvim_create_buf(false, true)
api.nvim_open_win(
  buf,
  true,
  { style = 'minimal', relative = 'win', row = 20, col = 20, width = 100, height = 20 }
)
api.nvim_buf_call(buf, function()
  vim.fn.jobstart({
    'fzf',
    '--preview='
      .. ('nvim -u NONE --server $NVIM --remote-expr %s'):format(
        fn.shellescape(
          ('nvim_open_win(nvim_create_buf(0, 1), 0, #{style:"minimal", relative:"editor", row:0, col:0, width:%s, height:%s})'):format(
            math.ceil(math.random() * 100),
            math.ceil(math.random() * 100)
          )
        )
      ),
    '--layout=default',
    '--preview-window=up:70%',
  }, { term = true })
  vim.cmd.startinsert()
end)

[ibhagwan]

lol @phanen, this messes up my neovim so good even after I leave the terminal the window is covered with grey squares hiding all the text:

Btw, I needed to add --preview-window=nohidden to trigger this (or toggle preview with a bind).

[ibhagwan]

@reybits, @miklhh, #1933 should work around this issue - will you test and reopen if otherwise?

[miklhh]

@ibhagwan, @phanen

Thank you both for the workaround. <3 I'll reopen and let you know should any problem persist!

[miklhh]

I just tried it out on caee132, which contains #1933, but the issue persists for me.

[phanen]

Is it better or worse or the same as before?

Ensure no other plugins is creating floating windows while you using fzf-lua (otherwise this may still happen). But I just use your config for a while but it didn't happen (tested on linux nvim 0.10/0.11).

[miklhh]

For me, the problem is as noticeable as before. I'm not really sure what's considered other floating windows, but I guess fidget.nvim might be a culprit? Or perhaps the preview window of require('fzf-lua').files()?

[miklhh]

Here is a short sequence of screenshots illustrating the rendering bug that I experience.

Notice especially:

• Between 1 and 2: The cursor jumps from the fzf search bar up one line and to the right
• Between 2 and 3: The letter 'a' has been duplicated to a new line. So has the fzf search bar (red >) and the fzf-selector (purple ◆).

1. Nvim command line: lua require('fzf-lua').buffers():

2. Keypress: a

3. Keypress: s

4. Keypress: d

[ibhagwan]

Ty for the feedback @miklhh, the “fix” applied in this issue is a best effort workaround, it’s unfortunate but I’m not sure what else is there to be done prior to the upstream being fixed.

I’ll reopen the issue so users can find this without searching.

[miklhh]

Thanks for reopening the issue @ibhagwan. As long as the problem is tracked somewhere, I am happy to wait for an upstream fix.

[miklhh]

Upstream issue: https://github.com/neovim/neovim/issues/33133

[ibhagwan]

FYI, this issue seems to be exacerbated with fzf_opts = { ["--layout"] = "default" }, having the prompt at the top this isn’t reproducible as easily for me.