Skip to content
This repository has been archived by the owner on Jun 6, 2024. It is now read-only.

v:count parameter passed to Lua functions causing conflicts #2

Open
nimaipatel opened this issue Sep 27, 2021 · 7 comments
Open

v:count parameter passed to Lua functions causing conflicts #2

nimaipatel opened this issue Sep 27, 2021 · 7 comments
Labels
bug Something isn't working
Projects

Comments

@nimaipatel
Copy link

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.

@b0o
Copy link
Owner

b0o commented 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
Copy link
Owner

b0o commented Sep 27, 2021

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.

@nimaipatel
Copy link
Author

nimaipatel commented 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

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
Copy link
Author

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)

@b0o
Copy link
Owner

b0o commented Sep 27, 2021

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)

@nimaipatel
Copy link
Author

Thank-you!

@b0o b0o added the bug Something isn't working label Nov 20, 2021
@b0o b0o changed the title Named functions not accepted as callbacks v:count parameter passed to Lua functions causing conflicts Nov 20, 2021
@b0o
Copy link
Owner

b0o commented Mar 27, 2022

This will be fixed in v1 as a breaking change.

@b0o b0o added this to To do in v1 Mar 27, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
v1
To do
Development

No branches or pull requests

2 participants