mapx.nvim icon indicating copy to clipboard operation
mapx.nvim copied to clipboard

`v:count` parameter passed to Lua functions causing conflicts

Open nimaipatel opened this issue 4 years ago • 7 comments

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:

  1. Mappings where the second argument is a string.
nnoremap('<leader>a', ':echo "using lua string"')
  1. Mappings where the second argument is an anonymous function.
nnoremap('<leader>b', function() print('using anonymous function') end)
  1. 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.

nimaipatel avatar Sep 27 '21 07:09 nimaipatel

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 avatar Sep 27 '21 07:09 b0o

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.

b0o avatar Sep 27 '21 08:09 b0o

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.

nimaipatel avatar Sep 27 '21 08:09 nimaipatel

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)

nimaipatel avatar Sep 27 '21 08:09 nimaipatel

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)

b0o avatar Sep 27 '21 08:09 b0o

Thank-you!

nimaipatel avatar Sep 27 '21 08:09 nimaipatel

This will be fixed in v1 as a breaking change.

b0o avatar Mar 27 '22 04:03 b0o