Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lazy.nvim resets custom mappings when using keys #191

Closed
ShaolunWang opened this issue Oct 9, 2023 · 12 comments
Closed

lazy.nvim resets custom mappings when using keys #191

ShaolunWang opened this issue Oct 9, 2023 · 12 comments

Comments

@ShaolunWang
Copy link

ShaolunWang commented Oct 9, 2023

As title suggested, if I map any key that is one of the default keys, e.g. s to bidirectional leap it only work once:

vim.keymap.set({ 'n', 'x', 'o' }, 's', function()
	local current_window = vim.fn.win_getid()
	require('leap').leap({ target_windows = { current_window } })
end, { noremap = true, desc = 'leap' })

And after leaping for the first time s would get remapped back to the default vim one. This might be caused by executing unbinding during every leap

@ggandor
Copy link
Owner

ggandor commented Oct 9, 2023

I cannot reproduce, the problem is not with this mapping itself, it should work.

@ShaolunWang
Copy link
Author

Right, thanks for confirming that!

@ShaolunWang
Copy link
Author

I just narrowed down the issue I had,fyi this is triggered by setting it like this:

require('lazy').setup({
  {
    'ggandor/leap.nvim',
    keys = {'s'} 
    -- with this keys lazy loading option,
    -- at each leap it calls lua/leap/main.lua: line 1202
    -- it also depends on the 
    -- and it will get reset to default vim s key
  }
})

vim.keymap.set({ 'n', 'x', 'o' }, 's', function()
  local current_window = vim.fn.win_getid()
  require('leap').leap({ target_windows = { current_window } })
end, { noremap = true})

Despite said here in the readme that lazy loading isn't necessary, there would potentially still be people like me who interpret the wording as lazy loading leap wouldn't result in unexpected behavior(s). Would it be possible to state this somewhere?

@ShaolunWang
Copy link
Author

@ggandor sorry for the ping, I forgot to reopen the issue. Could you please take another look?

@ShaolunWang ShaolunWang reopened this Oct 10, 2023
@ggandor
Copy link
Owner

ggandor commented Oct 20, 2023

Sure, but I don't fully understand the problem (what Lazy is doing in the background), and cannot really follow the comment in your code snippet, so please walk me through this then.

@ShaolunWang
Copy link
Author

So the problem I had was lazy would reset the keybinds when I use the lazy load on keypress option, if I decided to disable the default keymaps and only map s/S to leap actions. Those keybinds get reset to the vim s/S after the first leap action

@Sleepful
Copy link

did you try this?

require('lazy').setup({
  {
    'ggandor/leap.nvim',
    keys = {
        "s",
        function()
          require('leap').leap()
        end,
        mode = { "x", "n" },
        desc = "Leap",
      }
  }
})

@ShaolunWang
Copy link
Author

@Sleepful This would only work with the first leap. On the second leap it shows:

E5108: Error executing lua: ~/.local/share/nvim/lazy/leap.nvim/lua/leap/main.lua:405: attempt to index local '_local_67_' (a nil value)
stack traceback:
        ~/.local/share/nvim/lazy/leap.nvim/lua/leap/main.lua:405: in function 'leap'
        ~/.config/nvim/lua/plugins/leap.lua:11: in function <~/.config/nvim/lua/plugins/leap.lua:10>
        ```

@ggandor ggandor changed the title Custom leap with s/S will get remapped after the first jump lazy.nvim resets custom mappings when using keys Nov 25, 2023
@cd-a
Copy link

cd-a commented Jan 18, 2024

Did anyone find a solution to this?

@cd-a
Copy link

cd-a commented Jan 18, 2024

see LazyVim/LazyVim#2379 (comment) for solution

@ggandor
Copy link
Owner

ggandor commented Jan 18, 2024

TL;DR: don't use keys, it's unnecessary.

@ShaolunWang
Copy link
Author

ShaolunWang commented Jan 19, 2024

I will close it since it's not a leap issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants