Open chrisgrieser opened 5 months ago
I can't reproduce a glitch, so I'm shooting in the dark. I created a commit on the development branch which might fix it so install the development branch and report back to me if it fixed it. And if not, I would like a minimal reproducible config.
Okay, I did some testing, and it appears the issue only occurs in the lua ftplugin (nvim/after/ftplugin/lua.lua
). While normally, ftplugins only get loaded when entering the buffer, apparently, the autopairs somehow trigger ftplugin to be reloaded in the "incomplete" state (as it is currently edited)?
So this appears to be really an edge case and, nonetheless, it took me a bit to figure out that it is only this specific file.
I use vim.filetype.get_option()
to get filetype-specific options for injected (and non-injected) languages. This function loads ftplugin files.
I see, the error makes sense then.
So for now, it looks like this works as workaround
{
"<",
">",
ft = { "lua" },
cond = function(fn)
return fn.in_string() and not vim.endswith(vim.api.nvim_buf_get_name(0), "/ftplugin/lua.lua")
end,
},
Thanks for the nice plugin!
So, I often get errors when using a
in_string()
condition. In my case, I wanted to create a rule that pairs<>
in lua when inside a string (useful for writing keymaps such as"<CR>"
).Following the example in the docs, I added this to my config:
Which works, but errors quite often. For instance, when typing
"
here:I get this error:
I also check the
in_string
function in the code itself, and taking a guess from the function's signature, I also tried this;which does not appear to well either.