Yuriy Artemyev
Yuriy Artemyev
I'm returned to NVIM v0.7.0 (default from Fedora repo), and I have this problem.
[gruvbox-material](https://github.com/sainnhe/gruvbox-material)
No. The problem is still there.
> > It didn't take into account, that api.nvim_get_keymap returns the output in the form api.nvim_set_keymap accepts. So if key is mapped to Lua function, in the table that api.nvim_get_keymap...
> > Your check if layer is active was implicit, better make a boolean flag: it is easier to operate and harder to get confused. > > Could you be...
> Even though I like this change (and actually considered it for v3.0.0) it would be a breaking change for users who have been using libmodal.Layer since f84b028 released in...
About `Layer:unmap`. I get everything your wrote, but it is a bad design decision. User creates an object and want to manipulate it. And you give him this possibility with...
And why do you try to invent the wheel with next snippet: ```lua if self.existing_keymaps_by_mode then vim.notify( 'nvim-libmodal layer: This layer has already been entered. `:exit()` before entering again.', vim.log.levels.ERROR,...
Your current version also does not working. You check the buffer keymappings only if user pass `buffer` option. But he might not do it. And in this case layer will...
And in general: you get `existing_keymaps` from `api.nvim_get_keymap` and try to restore them with `vim.keymap.set`. This simply does not work. They are incompatible between each other.