`v:count` parameter passed to Lua functions causing conflicts
Hello, I really like the idea of this plugin and have something similar implemented in my dotfiles:
local escape_cmd = function(string)
return string:gsub("'", "\\'"):gsub('"', '\\"'):gsub('\\[', '\\['):gsub('\\]', '\\]'):gsub('<', '<lt>')
end
local bounded_funcs = 'global_bounded_funcs_namespace'
_G[bounded_funcs] = {}
for _, mode in ipairs { '', 'n', 'i', 'v', 't', 's' } do
_G[mode .. 'noremap'] = function(input, output)
if type(output) == 'function' then
local func_name = mode .. '_' .. input
local func_name_escaped = escape_cmd(func_name)
_G[bounded_funcs][func_name] = output
local lua_cmd = ':lua ' .. bounded_funcs .. "['" .. func_name_escaped .. "']()<cr>"
vim.api.nvim_set_keymap(mode, input, lua_cmd, { noremap = true, silent = true })
elseif type(output) == 'string' then
vim.api.nvim_set_keymap(mode, input, output, { noremap = true, silent = true })
else
error(mode .. 'noremap' .. ' expects a string or callback', 2)
end
end
end
This generates the [nivts]noremap family of functions which have two arguments. The first argument is the input keybinding and the second is either a string which can be a vim command OR it can be lua callback. This allows me to make the following types of mappings:
- Mappings where the second argument is a string.
nnoremap('<leader>a', ':echo "using lua string"')
- Mappings where the second argument is an anonymous function.
nnoremap('<leader>b', function() print('using anonymous function') end)
- Mappings where the second argument is a named function (useful for mapping functions provided by other plugins).
my_func = function() print('using named function') end
nnoremap('<leader>c', my_func)
I tried switching to mapx.nvim, mainly for the which-key.nvim integration and while example 1 and 2 work I'm not able to bind named functions. I know I can wrap the functions in an anonymous function but I'm just wondering why it doesn't work and what mistake I'm making.
That's odd, it should work in both cases and I do this quite often in my own config. I tested your third example and it works on my end. Can you share your full configuration?
Note that Lua functions are called with the value of v:count as their first argument (see the 2nd example in this snippet), this can trip up some use cases where the function treats that argument in a different way and could potentially fail. I may remove this behavior as it's only useful in certain cases, and in those cases the vim.v.count variable can be accessed instead.
Thank-you for the reply. Actually, named functions are working but for some reason I'm not able to bind functions from other plugins. It might be a lazy-loading misconfiguration by me in packer.nvim.
I ended up reducing my config to this and am still not able to figure out whats wrong though
local packer = require 'packer'
packer.startup(function(use)
use {
'nvim-telescope/telescope.nvim',
requires = 'b0o/mapx.nvim',
config = function()
local telescope = require 'telescope'
local builtin = require 'telescope.builtin'
local m = require 'mapx'
m.nnoremap('<c-p>', builtin.find_files)
end,
}
end)
The error:
E5108: Error executing lua vim/shared.lua:225: after the second argument: expected table, got number
stack traceback:
vim/shared.lua:225: in function 'tbl_extend'
...cker/start/telescope.nvim/lua/telescope/builtin/init.lua:490: in function 'func'
[string ":lua"]:1: in main chunk
I'm not able able to bind vim.lsp functions either.
This config works perfectly, though:
local packer = require 'packer'
packer.startup(function(use)
use {
'nvim-telescope/telescope.nvim',
requires = 'b0o/mapx.nvim',
config = function()
local telescope = require 'telescope'
local builtin = require 'telescope.builtin'
local m = require 'mapx'
m.nnoremap('<c-p>', function () builtin.find_files() end)
end,
}
end)
Yes, this is being caused by the v:count argument I mentioned. You can test it by running :lua require 'telescope.builtin'.find_files(0), it should give you that same error.
I regret this design decision and I'd like to remove it which would fix your issue. Unfortunately, it's difficult or impossible to detect whether or not someone is relying on this argument in order to give them a deprecation warning. I will consider how to best phase this out without breaking anyone's configurations.
In the mean time, you can do something like this as a workaround:
local function wrap(fn)
return function()
return fn()
end
end
local packer = require 'packer'
packer.startup(function(use)
use {
'nvim-telescope/telescope.nvim',
requires = 'b0o/mapx.nvim',
config = function()
local telescope = require 'telescope'
local builtin = require 'telescope.builtin'
local m = require 'mapx'
telescope.load_extension 'fzf'
m.nnoremap('<c-p>', wrap(builtin.find_files))
m.nnoremap('<c-t>', wrap(builtin.live_grep))
m.nnoremap('<c-b>', wrap(builtin.buffers))
end,
}
end)
Thank-you!
This will be fixed in v1 as a breaking change.