Need help to modify my config
Here's my original config:
require("better-n").setup {
callbacks = {
mapping_executed = function(_mode, _key)
-- Clear highlighting, indicating that `n` will not goto the next
-- highlighted search-term
vim.cmd [[ nohl ]]
end
},
mappings = {
-- I want `n` to always go forward, and `<s-n>` to always go backwards
["#"] = {previous = "n", next ="<s-n>"},
["F"] = {previous = ";", next = ","},
["T"] = {previous = ";", next = ","},
-- Setting `cmdline = true` ensures that `n` will only be
-- overwritten if the search command is succesfully executed
["?"] = {previous = "n", next ="<s-n>", cmdline = true},
-- I have <leader>hn/hp bound to git-hunk-next/prev
["]]"] = {previous = "[[", next = "]]"},
["[["] = {previous = "[[", next = "]]"},
["]m"] = {previous = "[m", next = "]m"},
["[m"] = {previous = "[m", next = "]m"},
}
}
I don't understand how to write new version config.
I can't even use default mapping with n during search or press * on a word, no matter disable_default_mappings is set to true or false.
Ah, this issue highlights some ergonomic issues with the new version.
In your case, I'd configure it like this:
local better_n = require("better-n")
local F = better_n.create({ key = "F", next = ",", previous = ";" })
vim.keymap.set({ "n", "x" }, "F", F.passthrough, { expr = true, silent = true })
local T = better_n.create({ key = "T", next = ",", previous = ";" })
vim.keymap.set({ "n", "x" }, "T", F.passthrough, { expr = true, silent = true })
local hash = better_n.create({ key = "#", next = "<s-n>", previous = "n" })
vim.keymap.set({ "n", "x" }, "#", hash.passthrough, { expr = true, silent = true })
better_n.create({ key = "?", next = "<s-n">, previous = "n" })
-- And then you need to map ]], [[, ]m, and [m "manually" i.e. find
-- whatever they are bound to and create a repeatable mapping for that action.
--
-- For gitsigns hunk navigation this would look like this
local hunk_navigation = require("better-n").create(
{
next = require("gitsigns").next_hunk,
previous = require("gitsigns").prev_hunk
}
)
vim.keymap.set({ "n", "x"}, "]h", hunk_navigation.next)
vim.keymap.set({ "n", "x"}, "[h", hunk_navigation.previous)
I also have a sneaking feeling that you are still mapping n and <s-n> manually. You either need to remove that mapping or change it like this:
vim.keymap.set({ "n", "x" }, "n", better_n.next, { expr = true, silent = true, nowait = true })
vim.keymap.set({ "n", "x" }, "<s-n>", better_n.previous, { expr = true, silent = true, nowait = true })
Due to some fundamental changes, these mappings now require expr = true set.
Simply remapping a given mapping to be repeatable is no longer supported, as it requires special handling.
It's something I am considering adding though.
@jonatan-branting
With the config you provided, I can use n and <s-n> with F, T, #.
And yes, I did mapping n and <s-n> manually, and I have removed the now.
I'd like to have use n and <s-n> after I press these keys-pairs: [[ and ]], ]m and [m, but I failed:
local two_square_brackets = better_n.create({ next = "n", previous = "<s-n>"})
vim.keymap.set({ "n", "x" }, "]]", two_square_brackets.next)
vim.keymap.set({ "n", "x" }, "[[", two_square_brackets.previous)
This looks like what you mean "Simply remapping"?
One more question is, where can we know to have key in require("better-n").create, and the property passthrough in the response?
local F = better_n.create({ key = "F", next = ",", previous = ";" })
vim.keymap.set({ "n", "x" }, "F", F.passthrough, { expr = true, silent = true })
With the rewrite, I wanted to get away from hooking into BufEnter to rebind everything, in case a buffer-local mapping overrode the mappings set by the plugin.
Instead, the idea was that if you have buffer-local mappings (filetype specific mappings first and foremost), you'd instead bind those on BufEnter yourself by creating a repeatable mapping using nvim-better-n.
Your use case highlight that this isn't very ergonomic, as you really have no control of some of those buffer local mappings. While there are ways of going around this, it's really not a good experience.
I think I'll have to come up with a way to support your use case better.