Asynchronously set keymaps that conflict are deleted and not restored

[Softsun2]

If keymaps are set asynchronously (such as on attach) they are deleted and not restored if they conflict with the lsp-overloads keymaps. I think this should at least be mentioned in the readme if this is desired behaviour. If not, maybe it's possible to update the original keymaps list with the current local buffer keymaps before activating the popup (and the lsp-overloads specific keymaps)?

Here's the function I'm calling in on_attach that I'm running into the issue with:

--Supports overloads for an lsp client. Can be provided as a
--callback for clients for languages that support function overloading.
local supportLspOverloads = function(client, bufnr)
    if client.server_capabilities.signatureHelpProvider then
        local opts = { buffer = bufnr, noremap = true, silent = false }
        vim.keymap.set("n", "<C-k>", "<cmd>LspOverloadsSignature<CR>", opts)
        Ss2.safeLoadModule("lsp-overloads").setup(client, {
            ui = { border = "single" },
            display_automatically = false,
        })
    end
end

After I leave the signature popup the first time my <C-k> keymap is deleted and restored to the default nvim behavior (digraphs) instead of my on attach keymap.

Instead of the using the on attach keymap my workaround is to use a global keymap that fails silently if LspOverloadsSignature is inaccessible:

vim.keymap.set("n", "<C-k>", function()
    pcall(vim.cmd, "LspOverloadsSignature")
end, opts)

PS thanks for your work! This is a great little plugin :)

[Issafalcon]

Hi @Softsun2 . Thanks for raising the issue! I did have this on my todo list to fix a while back, but it's one of those things that just dropped off my radar!

You're right in saying the keybinds should be restored to the their originals, if they conflict with one of the configurable keybinds in the options.

I'll take a look at this and hopefully come up with a solution.