Telescope stays in insert mode after picker is closed

[taketwo]

Description

I've started to experience the following annoying problem: after opening a file with Telescope find_files, Neovim goes into "insert" mode automatically. In fact, opening any Telescope picker and then just closing it, Neovim switches to "insert" mode. So far this affects only one of my machines that is on the most recent Neovim nightly (0.10.0~ubuntu1+git202311012034). My other machines (they share the same dotfiles and Lazy lockfile) have older nightlies (most recent is 0.10.0~ubuntu1+git202310091604) and don't seem to be affected.

I did some research are here are my findings.

Bisecting Telescope

I bisected Telescope history and found that with commit eb95a31 is the first one where the issue starts to happen. Older revisions are not affected.

Interaction with other plugins

Given that no-one else reported this problem, I tried to understand whether there was something special about my config. I "bisected" my plugins and found that it's the presence of https://github.com/romgrk/barbar.nvim that causes the issue. I then dug into their code and traced the problem to the following line: https://github.com/romgrk/barbar.nvim/blob/283bceab39f549c5e5228212661750704fcfcd9e/lua/barbar/state.lua#L103. Seems like reading buffer option during BufWinLeave event causes trouble.

MRE

I set up a custom callback for BufWinLeave and tried to access buffer options from there, and this still caused the issue, so we can exclude https://github.com/romgrk/barbar.nvim from the MRE. Some observations about the behavior of the MRE I provided:

• For some reason it's important to have at least two files open. If you start Neovim with one or no files, then the issue does not reproduce.
• It is access to buffer option via nvim_get_option_value that leads to reproduction. Calling other functions such as nvim_buf_get_name is okay.
• Note that there is a loop over buffers in MRE. When I just called nvim_get_option_value on current buffer, the issue did not reproduce. So it is access to some other buffer that causes trouble. I don't quite understand what that buffer is, but it has nofile type. I assume this is some auxiliary buffer that is created by Telescope.

Neovim version

$ nvim --version
NVIM v0.10.0-dev
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Run "nvim -V1 -v" for more info

$ apt-cache show neovim
Version: 0.10.0~ubuntu1+git202311012034-20dd9f3a2-c60402a16-cbebb8100~ubuntu20.04.1

Operating system and version

Ubuntu 20.04

Telescope version / branch / rev

Current HEAD (4522d7e)

checkhealth telescope

telescope: require("telescope.health").check()

Checking for required plugins
- OK plenary installed.
- WARNING nvim-treesitter not found. (Required for `:Telescope treesitter`.)

Checking external dependencies
- OK rg: found ripgrep 13.0.0
- OK fd: found fd 8.7.0

===== Installed extensions =====

Telescope Extension: `fzf`
- OK lib working as expected
- OK file_sorter correctly configured
- OK generic_sorter correctly configured

Steps to reproduce

1. nvim -nu minimal.lua file1 file2
   (the files don't have to exist, however it's important that there are at least two of them)
2. :Telescope find_files
3. Select some existing file and press enter

Expected behavior

File is opened and Neovim is in "normal" mode.

Actual behavior

File is opened and Neovim is in "insert" mode.

Minimal config

vim.cmd [[set runtimepath=$VIMRUNTIME]]
vim.cmd [[set packpath=/tmp/nvim/site]]
local package_root = '/tmp/nvim/site/pack'
local install_path = package_root .. '/packer/start/packer.nvim'
local function load_plugins()
  require('packer').startup {
    {
      'wbthomason/packer.nvim',
      {
        'nvim-telescope/telescope.nvim',
        requires = {
          'nvim-lua/plenary.nvim',
          { 'nvim-telescope/telescope-fzf-native.nvim', run = 'make' },
        },
      },
      -- ADD PLUGINS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
    },
    config = {
      package_root = package_root,
      compile_path = install_path .. '/plugin/packer_compiled.lua',
      display = { non_interactive = true },
    },
  }
end
_G.load_config = function()
  require('telescope').setup()
  require('telescope').load_extension('fzf')
  -- ADD INIT.LUA SETTINGS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
end
if vim.fn.isdirectory(install_path) == 0 then
  print("Installing Telescope and dependencies.")
  vim.fn.system { 'git', 'clone', '--depth=1', 'https://github.com/wbthomason/packer.nvim', install_path }
end
load_plugins()
require('packer').sync()
vim.cmd [[autocmd User PackerComplete ++once echo "Ready!" | lua load_config()]]

-- ABOVE IS THE STANDARD MINIMAL CONFIG
-- BELOW IS THE PART NEEDED FOR REPRODUCTION

vim.api.nvim_create_autocmd('BufWinLeave', {
  callback = function()
    print('BufWinLeave callback')
    for _, bufnr in ipairs(vim.api.nvim_list_bufs()) do
      print(bufnr, ' type: ', vim.api.nvim_get_option_value('buftype', { buf = bufnr }))
    end
  end,
})

[jamestrew]

Thanks for the detailed report!
I'm able to reproduce the issue with your MRE.

Unfortunately, this area of telescope's always been very difficult. Looks like the commit you bisected to was a revert commit for #2336 which was an attempt to fix another "cursor after picker is closed" issue.
We've had issues with upstream neovim forcing insert mode after closing a picker as well. #2501

[jamestrew]

It looks like with this specific MRE, wrapping the callback for BufWinLeave in a schedule_wrap solves the issue.
As for whether some sort of fix like this can be incorporated into telescope (or elsewhere) and if it won't break other things is the big question I don't have the answer to currently.

[mawkler]

I just wanna say that I had tried to debug this issue for a couple of hours now and was about to go crazy trying to find out exactly what was causing this bug in my config, since it requires a combination of plugins to appear. I also use barbar.nvim btw. I stumbled across this issue just now and realized that I'm not alone. Thanks for doing the lord's work and looking into this!

[wilriker]

I suffer from the same issue. When I was trying to debug it the other day (to me it was more or less loading of nvim-cmp with inconclusive combination of options) I went down from another angle and bisected upstream neovim and found that this commit is the first one to produce the issue - no versions of neovim before that commit had the issue (on my config) but all versions starting from this commit show the problem (to me also already when opening a Telescope picker in an otherwise empty neovim instance).

[taketwo]

@jamestrew Thanks for checking this out and also thanks for the pointer regarding schedule_wrap. I've tried to apply this workaround in Barbar and, based on my limited testing, it seems to solve the issue. I'll keep on using this workaround for a while and report if I notice any undesired side effects.

[fbernier]

@taketwo This fixes the issue for me too. Are you thinking of opening a PR on barbar? Let us know because if you don't I will.

[taketwo]

I've been using the workaround since last week and haven't noticed any side-effects, though I did not do much coding in this period. If you have free cycles, you are welcome to send a PR to Barbar.

[gbprod]

Hey, I think we can close this issue as it's fixed by romgrk/barbar.nvim#540 ;)

[taketwo]

@gbprod Thanks for taking the time to submit a PR! This mitigates the issue for Barbar users. However, since the issue itself is not Barbar-specific, I believe the ticket should remain open.

[devenv]

Temporary pain relief:

vim.api.nvim_create_autocmd("WinLeave", {
  callback = function()
    if vim.bo.ft == "TelescopePrompt" and vim.fn.mode() == "i" then
      vim.api.nvim_feedkeys(vim.api.nvim_replace_termcodes("<Esc>", true, false, true), "i", false)
    end
  end,
})

courtesy of: #2027 (comment)

[tbung]

I have this issue with terminal buffers. Since this happens with nothing but telescope installed it might be a different but related issue.

Minimal init.lua:

local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({
    "git",
    "clone",
    "--filter=blob:none",
    "https://github.com/folke/lazy.nvim.git",
    "--branch=stable", -- latest stable release
    lazypath,
  })
end
vim.opt.rtp:prepend(lazypath)

require("lazy").setup({
  {
    "nvim-telescope/telescope.nvim",
    dependencies = { "nvim-lua/plenary.nvim" },
  },
})

Then do

:term
:Telescope buffers

and go to the terminal buffer again.

Since this enters terminal mode, the workaround has to be changed to

vim.api.nvim_create_autocmd("WinLeave", {
  callback = function()
    if vim.bo.ft == "TelescopePrompt" and vim.fn.mode() == "i" then
      vim.api.nvim_feedkeys(vim.api.nvim_replace_termcodes([[<C-\><C-n>]], true, false, true), "i", false)
    end
  end,
})

[jamestrew]

@tbung we're tracking this related but separate issue #2785

[jamestrew]

This is now fixed upstream via neovim/neovim#27051

@taketwo your MRE was tremendously helpful 🙏

[taketwo]

I can confirm that the issue does not reproduce on the new Neovim nightly. Also, the old unpatched version of Barbar does not cause trouble now.

@jamestrew Thanks for investigating and propagating the bug report to Neovim. And I see that the patch even reached upstream Vim :)