better-escape.nvim
better-escape.nvim copied to clipboard
feat: allow more than 2 keys
fixes #106 Because you can make the preceded characters and set them to "" to disable the plugin:
v = {
j = {
j = {
k = "",
},
}
},
This example fixes https://github.com/max397574/better-escape.nvim/issues/106#issuecomment-2607330551
It's a draft because I am not sure if there are any bugs. It seems to work fine though. Also because the commits are a mess.
@max397574 What the point of unmap_keys (formally clear_mappings) ? vim.keymap.set already overwrites old mappings.
Never mind it clears the mappings when setup() is called 2 times.
👀
busy this weekend, will look into it next week
I should probably add some readme examples for this. I was waiting for #112 to be merged.
turned out I was busy for more than one week 😅
Code looks good to me I'll tests this myself locally for a few days before merging it (I guess you already have used this for some time yourself?)
(I guess you already have used this for some time yourself?)
No, I actually haven't been coding that much for the last few weeks because of school, but I did test the code a bit.
When I use jk to esc (with mappings from default config)
the cursor moves up a line when on an empty line
not 100% sure yet what in the code causes this regression
Uh, It also deletes the previous character on non empty lines. Found a fix though.
Nvm the fix breaks if a key has multiple parents.
somehow this also broke with this pr
i = {
[" "] = {
["<TAB>"] = function()
vim.defer_fn(function()
vim.o.ul = vim.o.ul
require("luasnip").expand()
end, 1)
end,
},
},
},
How did it break ? What happens ?
Oh the plugin maps " <Tab" as parents for the sequence " <Tab>".
We could fix it by simply removing the multiple keys layout(https://github.com/max397574/better-escape.nvim/pull/113/commits/13306ef3f62f523fb6adb91ad676b6c7495797a8) or dirty fix it by translating the key to escape codes then checking if the string changes. If https://github.com/neovim/neovim/issues/26575 were fixed, it could allow us to just parse the keys.
Both issues should be fixed now. But there's still a bug where the plugin overdeletes if you map multiple special characters:
i = {
["<Tab>"] = {
["<Tab>"] = "<Esc>",
},
},
I don't think it's relevant enough to fix.
perhaps we should just mention this somewhere in the readme that it's a known limitation
perhaps we should just mention this somewhere in the readme
I was gonna do that. I wanted to discuss it first in case you had a solution or if there was a use case for special characters that we could hardcode.
Also I misunderstood the issue: the bug only happens if the special key is not the final key in a mapping, heres a better example:
i = {
["<Tab>"] = {
j = "<Esc>",
},
},