bug: lazy.nvim keymap disables, when filetypes are given and other keymaps are used before

[kalocsaibotond]

Did you check docs and existing issues?

• I have read all the lazy.nvim docs
• I have searched the existing issues of lazy.nvim
• I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

0.9.5 stable release

Operating system/version

Windows 10 Pro/10.0.19045 Build 19045

Describe the bug

For a plugin specification, if I specify the filetypes for certain lazy.nvim keymaps and open one specified file, then if I use a plugin related lazy.nvim keymap, all of the other non-used lazy.nvim keymaps for which filetypes are specified become disabled.

Consequently, if the first used plugin related lazy.nvim keymap has filetype specification, then that keymap remains enabled and the rest filetype specified lazy.nvim keymap become disabled throughout the Neovim session.

I discovered this bug while I included yarepl.nvim plugin into my LazyVim setup, and I wanted to specify an "Open REPL Here" keymap to only show up for filetypes for which I defined REPLs.

Steps To Reproduce

1. Take a plugin whose effective usage assume keymaps and you want to include into your config with lazy.nvim.
2. Specify keymaps for the plugin with lazy.nvim.
3. For some keymaps specify filetypes using the ft key of LazyKeysSpec table.
4. Open a file that matches one of the specified filetypes.
5. Use a plugin related keymap that you specified in step 2..
6. Try to use other keymaps that has filetype specification which matches the currently opened file.

Expected Behavior

The operation defined in the rhs of the keymap does not applies.

Repro

-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/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", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  -- add any other plugins here
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here

[dpetka2001]

I don't understand what you're saying. I tried your dotfiles and it seems to work as intended. Screencast following

Screencast.2024-05-14.21.04.25.webm

Here you can see that I uncommented ft = fts for <LocalLeader>ro (Open Repl here) and then I open 2 files, a python file and a toml file and you can see that <LocalLeader>ro is mapped correctly for the Python file, whereas for the toml file you can see that it's not mapped.

Or am I misunderstanding you in some way?

[kalocsaibotond]

I don't understand what you're saying. I tried your dotfiles and it seems to work as intended. Screencast following

Screencast.2024-05-14.21.04.25.webm
Here you can see that I uncommented ft = fts for <LocalLeader>ro (Open Repl here) and then I open 2 files, a python file and a toml file and you can see that <LocalLeader>ro is mapped correctly for the Python file, whereas for the toml file you can see that it's not mapped.

Or am I misunderstanding you in some way?

The logic of the bug is difficult to explain, but it is simple. If I understand your point well, then you seem to misunderstand it.
There is no problem, with the buffer dependenent assignment of the keymaps. It assigns where it ought to and does not assigns where it ought not to.

Let us look at just two keymaps: <LocalLeader>ro (Open Repl here), <LocalLeader>r? (Open Repl).
For the <LocalLeader>ro keymap let us assume that ft = fts was set.

Let us take a python file for which we have a defined REPL.

When I open the file with my LazyVim config, use the <LocalLeader>r? keymap (to open a REPL, exit the REPL,) then the <LocalLeader>ro keymap disables i. e. it's assignment remains (as shown by which-key) but it no longer works. The This is an example of the manifestation of the buggy behaviour.

On the other hand, If use <LocalLeader>ro first, then everything works fine.

If no ft = fts was set, then also everything works fine.

[dpetka2001]

Screencast.2024-05-15.14.54.33.webm

I just did exactly what you said and it functions as it should. I opened a Python file, first did <LocalLeader>r? to choose from the list of repls and after it opened I exited the REPL. Then I did <LocalLeader>ro and it opened directly the REPL.

I just cloned your own dotfiles and use them as Neovim configuration.

[kalocsaibotond]

Screencast.2024-05-15.14.54.33.webm
I just did exactly what you said and it functions as it should. I opened a Python file, first did <LocalLeader>r? to choose from the list of repls and after it opened I exited the REPL. Then I did <LocalLeader>ro and it opened directly the REPL.

I just cloned your own dotfiles and use them as Neovim configuration.

Intriguing. This bug seems to be quite elusive:

lazy_keymap_bug.webm

I surmise that this bug has to do with the platform. Perhaps, it emerges from a bug in the Neovim API on Windows 10 and the way lazy.nvim interacts with it.

What OS did you use (, it looks like a unix derivative)?

Anyway, thank you for testing my LazyVim - yarepl setup. Your test proves that the bug does not come from my configuration.

[dpetka2001]

Yes, I use Linux Mint 21.3. Maybe the problem is with the plugin yarepl itself. Here is a pretty simple repro

-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
	vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/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", lazypath })
end
vim.opt.runtimepath:prepend(lazypath)

vim.g.mapleader = " "
vim.opt.timeoutlen = 300

-- install plugins
local plugins = {
	"folke/tokyonight.nvim",
	{ "folke/which-key.nvim", opts = {} },
	{
		"nvim-telescope/telescope.nvim",
		dependencies = { "nvim-lua/plenary.nvim" },
		keys = {
			{ "<leader>ff", "<cmd>Telescope find_files<cr>", desc = "Find files" },
			{ "<leader>fg", "<cmd>Telescope live_grep<cr>", ft = "python", desc = "Live grep" },
		},
	},
	-- add any other plugins here
}
require("lazy").setup(plugins, {
	root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here

Save this as repro.lua in your config directory and run it as nvim -u repro.lua. Open 2 files. One Python file and another filetype. <leader>fg should only be available in the Python file. I first press <leader>ff which does not have a ft property and then press <leader>ff which does have ft = "python" property. Both execute as they should.

Try to reproduce and report back your findings.

[kalocsaibotond]

Yes, I use Linux Mint 21.3. Maybe the problem is with the plugin yarepl itself. Here is a pretty simple repro

-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
	vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/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", lazypath })
end
vim.opt.runtimepath:prepend(lazypath)

vim.g.mapleader = " "
vim.opt.timeoutlen = 300

-- install plugins
local plugins = {
	"folke/tokyonight.nvim",
	{ "folke/which-key.nvim", opts = {} },
	{
		"nvim-telescope/telescope.nvim",
		dependencies = { "nvim-lua/plenary.nvim" },
		keys = {
			{ "<leader>ff", "<cmd>Telescope find_files<cr>", desc = "Find files" },
			{ "<leader>fg", "<cmd>Telescope live_grep<cr>", ft = "python", desc = "Live grep" },
		},
	},
	-- add any other plugins here
}
require("lazy").setup(plugins, {
	root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here

Save this as repro.lua in your config directory and run it as nvim -u repro.lua. Open 2 files. One Python file and another filetype. <leader>fg should only be available in the Python file. I first press <leader>ff which does not have a ft property and then press <leader>ff which does have ft = "python" property. Both execute as they should.

Try to reproduce and report back your findings.

I managed to reproduce the bug consistently, even for this testing configuration:

lazy_keymap_bug2.webm

[dpetka2001]

After you close Telescope find_files are you able to invoke the keymap <leader>ff again? Or do you also have to write the command :Telescope find_files to open it again?

[dpetka2001]

Ok I can reproduce as well. Before, I was testing with Neovim nightly and could not reproduce it. I switched to Neovim 0.9.5 and can reproduce now. Indeed when you first invoke a keymap which does not have a ft property defined, the keymaps with ft property defined don't work. So, it seems to be something that conflicts with Neovim API in the stable version, because with nightly it works just fine.

[kalocsaibotond]

After you close Telescope find_files are you able to invoke the keymap <leader>ff again? Or do you also have to write the command :Telescope find_files to open it again?

The <leader>ff keymap works everywhere flawlessly. I can invoke the <leader>ff keymap again after closing Telescope find_files. I do not need to write the :Telescope find_files command to open it again.

[folke]

Thank you all for investigating this! Since it seems to work fine on Nightly, I'll close this.

[dpetka2001]

@folke Is it something that needs to be reported in Neovim upstream or is it something that needs to be taken into account by lazy.nvim when someone uses Neovim stable? I don't really understand what's going on, hence my question about this. I rarely use Neovim stable either way, except for testing purposes, so this doesn't really affect me either way.

[folke]

Since this is the first time it came up, it seems not a lot of people are hitting this issue.
I'd just leave it all as is right now, especially since it seems to be fixed on nightly.

[kalocsaibotond]

Ok I can reproduce as well. Before, I was testing with Neovim nightly and could not reproduce it. I switched to Neovim 0.9.5 and can reproduce now. Indeed when you first invoke a keymap which does not have a ft property defined, the keymaps with ft property defined don't work. So, it seems to be something that conflicts with Neovim API in the stable version, because with nightly it works just fine.

I have tested it with the freshly released Neovim 0.10.0 stable, (using the repro.lua as instructed), and unfortunately the bug still prevails. It seems that the modification in the nighly did not made it into the stable release.

[dpetka2001]

@folke With some hesitation as to how complete my suggestion might be I believe I found the culprit here

lazy.nvim/lua/lazy/core/handler/keys.lua

Lines 176 to 178 in 0de782a

	if not keys.ft then
	self:_set(keys)
	end

Changing that to

  if not keys.ft then
    self:_set(keys)
  else
    self:_set(keys, vim.api.nvim_get_current_buf())
  end

seems to solve the issue for me locally. Hesitant to make a PR as I mostly went about it with prints in the handler/keys.lua, where I observed that the keys that didn't have ft property made another call to M:_set(), which didn't seem to happen for the keys with ft property, when another key with no ft property was pressed first.

So, when deleting the keys here

lazy.nvim/lua/lazy/core/handler/keys.lua

Line 116 in 0de782a

self:_del(keys)

The _del method should re-add the keys but it only seems to do that for keys that have no ft property??

PS: Still that only happens in the first opened buffer. If I do nvim test.py test2.py, for example, it only happens in the first buffer test.py. If I change to the second buffer test2.py I can do <leader>ff and then <leader>fg without any problem (<leader>ff has no ft property and <leader>fg has ft = "python"), so maybe I'm missing something else that causes this.

[folke]

Thank you all for looking into this!

@dpetka2001 that was indeed part of the problem, but the current code did not cleanup the other lazy ft keymaps.

I just pushed a changed this fixes all of this.

@kalocsaibotond would be great if you could confirm everytihng is working now!

[dpetka2001]

Can confirm it's working for me locally with lazy.nvim HEAD.

[kalocsaibotond]

Thank you all for looking into this!

@dpetka2001 that was indeed part of the problem, but the current code did not cleanup the other lazy ft keymaps.

I just pushed a changed this fixes all of this.

@kalocsaibotond would be great if you could confirm everytihng is working now!

I have tried it out the 9895337 commit of lazy.nvim with the repro.lua and it seemed to work well.

However, when I tried it on my main LazyVim config that is in my dotfiles, Neovim freezes (I used the usual \ro keymap that opens a repl as before). It freezes so much that I cannot even quit Neovim.

As a context, in my main config, I updated 758bb5d to 9895337 manually using the lazy-lock.json and the restore option in lazy.nvim. Otherwise I try to keep my lazy.lua file synchronised with the starter template.

[dpetka2001]

That's not how you update lazy.nvim to follow HEAD in LazyVim. Please see the docs for how to do that. Or wait for the next lazy.nvim release.

[kalocsaibotond]

That's not how you update lazy.nvim to follow HEAD in LazyVim. Please see the docs for how to do that. Or wait for the next lazy.nvim release.

I tried out the installation via putting ~/.config/nvim/lua/plugins/core.lua with the following content:

return {
  { "folke/lazy.nvim", version = false },
}

. I also tried out with the content

return {
  { "folke/lazy.nvim", version = false },
  { "LazyVim/LazyVim", version = false },
}

.
Unfortunately, the result is the same, complete freezing.

[dpetka2001]

Not entirely sure, but seems like these lines that got removed

-- Create the real buffer-local mapping
      if keys.ft then
        self:_set(keys, buf)
      end

are needed. When I add them back the keys work and it doesn't freeze even with your dotfiles that I'm trying. Without this change your dotfiles would indeed freeze.

Let's wait for maintainer's input for better insight.

[dpetka2001]

@folke I believe I might have an idea why this happens

lazy.nvim/lua/lazy/core/handler/keys.lua

Lines 166 to 170 in 9895337

	local bufs = keys.ft
	and vim.tbl_filter(function(buf)
	return vim.bo[buf].filetype == keys.ft
	end, vim.api.nvim_list_bufs())
	or { false }

Line 168 doesn't take into account if ft is a list of strings. And that's how the OP has it in his configuration ft = { "sh", "bat", "ps1", "REPL", "python" }. I tried but couldn't make it work. Sorry about that. Hopefully, this will let you think of a better solution.

[folke]

Great! That was indeed wrong. Just fixed that.
Would be great if you can confirm it now works as expected. Thanks!

[dpetka2001]

I just tried with OP's dotfiles and it works now on my end without freezing. It would be great if @kalocsaibotond could confirm on his end as well. Hope I'm not missing something.

[kalocsaibotond]

I just tried with OP's dotfiles and it works now on my end without freezing. It would be great if @kalocsaibotond could confirm on his end as well. Hope I'm not missing something.

I tested the 8f19915 commit of lazy.nvim with my dotfiles and it seemed to work by the documentation. Finally, the bug seems to be eliminated.