Closed kalocsaibotond closed 3 months ago
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?
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.
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.
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:
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.
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.
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 asnvim -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 aft
property and then press<leader>ff
which does haveft = "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:
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?
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.
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.
Thank you all for investigating this! Since it seems to work fine on Nightly, I'll close this.
@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.
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.
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 withft
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.
@folke With some hesitation as to how complete my suggestion might be I believe I found the culprit here https://github.com/folke/lazy.nvim/blob/0de782a6b0ffba599dbd332a4019d852564bf28c/lua/lazy/core/handler/keys.lua#L176-L178
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 https://github.com/folke/lazy.nvim/blob/0de782a6b0ffba599dbd332a4019d852564bf28c/lua/lazy/core/handler/keys.lua#L116
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.
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!
Can confirm it's working for me locally with lazy.nvim
HEAD.
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.
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.
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 nextlazy.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.
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.
@folke I believe I might have an idea why this happens https://github.com/folke/lazy.nvim/blob/9895337d1f4c0cea1186d92148e3d80f6551eda8/lua/lazy/core/handler/keys.lua#L166-L170
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.
Great! That was indeed wrong. Just fixed that. Would be great if you can confirm it now works as expected. Thanks!
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 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.
Did you check docs and existing issues?
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
ft
key ofLazyKeysSpec
table.Expected Behavior
The operation defined in the rhs of the keymap does not applies.
Repro