Bug: commit `f611dc2` breaks `<CR>` when having a `=` keymap
chrisgrieser opened this issue · comments
Description
commit f611dc2
breaks <CR>
when having a =
keymap
Mapping bug
No response
Steps to reproduce
- be on
f611dc2
- add something like
vim.keymap.set("n", "=", "kkk")
- use this snippet:
-- | = cursor location
foobar = {|}
- Press
enter
Result: the =
mapping takes effect, moving the cursor incorrectly upwards.
Issue does not occur for me on 3b664e8
Minimal config
local root = vim.fn.fnamemodify("./.repro", ":p")
for _, name in ipairs { "config", "data", "state", "cache" } do
vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end
--------------------------------------------------------------------------------
local plugins = {
{ "windwp/nvim-autopairs", opts = true }
}
vim.keymap.set("n", "=", "kkk")
--------------------------------------------------------------------------------
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",
lazypath,
}
end
vim.opt.runtimepath:prepend(lazypath)
require("lazy").setup(plugins)
i used recursive mapping for = just incase a formatter uses it (sorry)
i didn't know it would lead to issues like this i think it's better using the default mapping
ill just remove all recursive mapping in my current pr
just incase a formatter uses it
Formatter normally plugs themself into neovim using formatexpr
or formatprg
options, not by hijacking key mappings, so it is the right behavior to use noremap here.
yea and equalprg
i forgot about that when i read :normal
's docs
i just learnt everything i know about vim plugin development in like 4 days so it's a got a bit overwhelming
nevertheless i should have probably thought twice before adding recursive mapping to the pr
thanks, issue is fixed with that commit 👍