Autoclose breaks <C-h> mapping

[NielsCodes]

I have the following keymaps in my config:

vim.keymap.set("i", "<C-h>", "<Left>", {})
vim.keymap.set("i", "<C-l>", "<Right>", {})
vim.keymap.set("i", "<C-j>", "<Down>", {})
vim.keymap.set("i", "<C-k>", "<Up>", {})

This is so I can navigate through a line with Control + hjkl while in insert mode. However, Ctrl + h would not move the cursor, but instead it would perform a backspace.

This lead me down a rabbit hole of mapping issues like this thread and this one.

After a lot of trial and just as much error, I came to the conclusion that it was actually this plugin that was breaking my keymap.

[NielsCodes]

And for anyone wondering how I fixed it: I switched to nvim-autopairs instead.

[telemachus]

C-h has a built-in function in insert mode and in command mode: it deletes the previous character. This plugin assumes that as a default, and preserves that behavior. That makes sense, from one point of view, since it is the default behavior of C-h in insert and command mode.

On the other hand, I see from your links that C-h as <Left> in insert mode is a reasonably popular custom mapping. This is a general problem for {neo,}vim plugins: they may create mappings that mess with a user's mappings. I'm not sure what the right response is here. One thought is that the plugin could offer a configuration option to opt-out of remapping C-h in one or more modes. We'll see what @m4xshen thinks though.

[NielsCodes]

@telemachus I see your point about respecting defaults and I know that <C-h> is a special case, but I personally don't agree that it makes sense for a plugin to assume this (or any other) default mapping is actually in use.

And maybe for a little context as to why this <Left> mapping is so popular: Using Tmux + Neovim and something like vim-tmux-navigator, you can easily move between all your terminal panes and Neovim windows with CTRL + hjkl. Being able to use those same keymaps for navigation within insert mode is great, because navigation works the same way regardless of the level at which you're navigating. It's 100% muscle memory at this point, so not being able to use that keymap is a deal-breaker for me.

[telemachus]

I personally don't agree that it makes sense for a plugin to assume this (or any other) default mapping is actually in use

Fair enough (though probably awfully complicated in practice). In this case, I suspect that if the mapping added unique, that might fix the problem. I maintain a fork of this repo (with some tweaks), and I'll test it out there. If things work out, I'll submit a PR here and ping you. Also, as I said originally, the plugin's creator may have other thoughts too.

[telemachus]

@NielsCodes If you have time, try my fork using the "mapcheck" branch. It wasn't a lot of code, but I need to test it further and think about it more before I make a pull request.

Note to self and for Max: my current stab at this means that <C-W> will also not be mapped or special-handled by autoclose. Why not? Because neovim itself remaps <C-W> in _defaults.lua. I fixed this problem, but it's still a good example of how complicated things get.

[NielsCodes]

@telemachus sorry for the delay. I tried your fork and it still does not seem to work. I appreciate you looking into this, but I guess I'm pretty happy with nvim-autopairs now. So if it's a pain to implement, I don't want to waste your time on this either.

[telemachus]

@NielsCodes No problem. I have a few other ideas, but if you found something you're happy with, I'm glad.