You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jun 6, 2024. It is now read-only.
Repository navigation
This repository was archived by the owner on Jun 6, 2024. It is now read-only.
v:count parameter passed to Lua functions causing conflicts #2
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.
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.
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:
Activity
b0o commentedon Sep 27, 2021
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?
b0o commentedon Sep 27, 2021
Note that Lua functions are called with the value of
v:countas 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 thevim.v.countvariable can be accessed instead.nimaipatel commentedon Sep 27, 2021
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
The error:
I'm not able able to bind
vim.lspfunctions either.nimaipatel commentedon Sep 27, 2021
This config works perfectly, though:
b0o commentedon Sep 27, 2021
Yes, this is being caused by the
v:countargument 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:
nimaipatel commentedon Sep 27, 2021
Thank-you!
[-]Named functions not accepted as callbacks[/-][+]`v:count` parameter passed to Lua functions causing conflicts[/+]b0o commentedon Mar 27, 2022
This will be fixed in v1 as a breaking change.