fix: allow lambdas and Lua functions as doc handlers #3151
Conversation
When `g:vimtex_doc_handlers` holds a lambda expression or bare Lua function, the iterator itself will become a Funcref. To avoid E704, this Funcref variable name must start with a capital letter.
|
By the way, I'd be really happy if someone can explain to me why
While the error message suggests that the Lua function I passed is now held as a Funcref:
Is this because the bare Lua function is treated the same as a lambda expression when handled inside Vim script? This is at least the behavior I observed, but I couldn't find any conclusive information in the Neovim docs or online. So if my reasoning in the commit text is wrong, feel free to correct me :) And a note for anyone considering using a Lua function: From inside Lua, there's absolutely no way1 to modify the
So one will want to implement all the doc-handling logic inside the function, not relying on handlers down the list to open the selected candidate. Alternatively, use a Vimscript wrapper to modify the dictionary. Footnotes
|
|
Sorry for the slow response!
Yes, that's right, and I think your change is both safe and useful! Thanks!
I'm sorry, I can't explain that.
Thanks, that's useful to know. And yes, I think you are right that there is no way to change the vimscript reference of the In any case, thanks for the contribution! |
No worries at all! I appreciate your feedback. I'm genuinely impressed that you've been actively maintaining this plugin for so many years – huge thanks for your dedication! |
Great, and thanks for the kind words! It's been fun to keep working on this. 😊 |
When
g:vimtex_doc_handlersholds a lambda expression or bare Lua function, the iterator itself will become a Funcref. To avoid E704, this Funcref variable name must start with a capital letter.In practice, this means one can directly pass in a Lua function:
Instead of having to create a Vim wrapper function, which can be
call()ed directly by its name: