Bug: FzfLua buffers closes/deletes terminal buffers

[mikesmithgh]

RTFM Checklist

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

Operating system

MacOS

Shell

fish

Neovim version (nvim --version)

NVIM v0.12.1

Fzf version (fzf --version)

0.71.0 (Homebrew)

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

--border=thinblock --scrollbar=▊ --preview-window=60%,border-thinblock --margin 1,4 --multi --layout=reverse --scroll-off=7 --height=100% --bind "alt-a:toggle-all" --history /Users/mike/.local/state/fzf/history.txt --history-size=100000 --cycle --info=inline-right --ellipsis=… --separator=─ --pointer=󰅂 --no-separator --marker=﹢ --prompt="$ " --color='spinner:#8faa80:bold,fg:#c7c7c7,pointer:#ff6961:bold,preview-label:#504945:bold,hl+:#dbbc5f:bold:reverse,label:#504945:reverse:bold,bg+:#32302f,fg+:#a0a0a0:bold,info:#8faa80,query:#c7c7c7:bold,preview-bg:#070707,separator:#504945,disabled:#968c81:regular,border:#504945,prompt:#83a598,bg:#1a1a1a,hl:#a9d5c4:bold:reverse,gutter:#1a1a1a,marker:#d3869b:bold,preview-fg:#c7c7c7,scrollbar:#504945,header:#968c81'

Is the problem reproducible with mini.sh?

• My issue is reproducible with mini.sh
• 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({
})

Describe the bug / steps to reproduce

Steps

• Open a terminal buffer, e.g., run the command :term echo hi
• Open a file in another buffer, e.g., :e README.md
• Execute :FzfLua buffers
• Select the terminal buffer
• Once you have focus on the buffer, press any key, e.g., j

Actual

The terminal buffer automatically closes and is deleted.

Expected

The terminal buffer does not close.

Demo

fzf-lua-buffer-term-issue.mp4

[phanen]

:exe "vert te ls" | wincmd w | FzfLua buffers

[phanen]

Similar to #2482

[phanen]

Lol copilot don't seems understand well on this https://github.com/ibhagwan/fzf-lua/tasks/0c1f8a7d-31f3-4a8a-9be3-8c117d917310

[phanen]

exe "vert te ls" | stopinsert | wincmd w | FzfLua buffers

[phanen]

Revert in 7972e2a, since it cause other issue.

To fix this we have to be careful :

1. FzfLua builtin don't startinsert on new picker since #2682 #2683: FzfLua builtin don't startinsert on new picer
2. utils.feed_keys_termcodes("i") insert char on e.g. alt-i

[mikesmithgh]

@phanen I think there is some race condition, but not quite sure.

I locally modified

fzf-lua/lua/fzf-lua/actions.lua

Line 208 in cebf888

(function()

by adding vim.defer_fn(function() ... end, 100)

then I don't see the issue. Probably not the correct solution but just playing around.

I also think it is weird in general that if you enter insert mode in a terminal Neovim's default behavior is to delete the buffer. I wonder if it would make sense to have a feature request in Neovim to change that behavior. Like noop or just give a message to the user that they can't edit the buffer.

[phanen]

I also think it is weird in general that if you enter insert mode in a terminal Neovim's default behavior is to delete the buffer. I wonder if it would make sense to have a feature request in Neovim to change that behavior. Like noop or just give a message to the user that they can't edit the buffer.

Yeah, I think this can be annoying sometime, but it's still scriptable.

vim.on_key(function(_, k)
  local redir = vim.api.nvim_get_mode().mode == 't'
      and vim.api.nvim_get_chan_info(vim.bo.channel).exitcode >= 0
      and (k:match('%a') or k == vim.keycode('<esc>'))
      and true
    or false
  if redir then
    vim.api.nvim_feedkeys(vim.keycode('<c-\\><c-n>' .. k), 'nt', false)
    return ''
  end
end, vim.api.nvim_create_namespace(''))

[phanen]

by adding vim.defer_fn(function() ... end, 100)

That's interesting, even delay=0 work for me.

diff --git a/lua/fzf-lua/actions.lua b/lua/fzf-lua/actions.lua
index a2745f7..f99a122 100644
--- a/lua/fzf-lua/actions.lua
+++ b/lua/fzf-lua/actions.lua
@@ -203,7 +203,7 @@ end
 ---@param opts fzf-lua.config.Resolved|{}
 ---@param bufedit boolean?
 ---@return string?
-M.vimcmd_entry = function(vimcmd, selected, opts, bufedit)
+local vimcmd_entry = function(vimcmd, selected, opts, bufedit)
   for i, sel in ipairs(selected) do
     (function()
       -- Lua 5.1 goto compatiblity hack (function wrap)
@@ -282,6 +282,11 @@ M.vimcmd_entry = function(vimcmd, selected, opts, bufedit)
   end
 end
 
+M.vimcmd_entry = function(...)
+  local args, n = { ... }, select("#", ...)
+  vim.defer_fn(function() vimcmd_entry(unpack(args, 1, n)) end, 0)
+end
+
 -- file actions
 M.file_edit = function(selected, opts)
   M.vimcmd_entry(nil, selected, opts, true)

EDIT:
minimal repro

vim.cmd("vert term ls")
local ls_buf = vim.api.nvim_get_current_buf()
-- print(ls_buf)
vim.cmd.stopinsert()
vim.cmd.wincmd("p")

local buf = vim.api.nvim_create_buf(false, true)
local win = vim.api.nvim_open_win(buf, true, { relative = "editor", width = 10, height = 10, row = 10, col = 10, style = "minimal", border = "none" })
vim.fn.jobstart("sleep INF", { term = true })
vim.cmd.startinsert()


vim.defer_fn(function()
	vim.api.nvim_win_hide(win)
	vim.defer_fn(function() vim.cmd.b(ls_buf) end, 10)
	-- vim.cmd.b(ls_buf)
end, 100)

The reason seems #2054 (comment).

We previous rely on "switch from terminal buffer to normal buffer" to help us to resume to normal mode, but action set_buf to switch to a terminal buffer again before the modechange