tl.loader()
performance implications?
#513
-
Hi, I'm very interested in Teal, it looks awesome. I'm considering rewriting parts of my Neovim plugin in Teal to help with documentation (I think there's some docs generators for Teal), and I'm trying to plan my approach. I see the main approach used by Neovim plugins written in Teal is to commit the compiled Lua to source control (because of the way Neovim plugin managers work, the plugin files need to be right in the repo). This is fine, but I'd like to avoid the need to store compiled files in source control, which brings me to my question about What are the performance implications of |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
But as far as not wanting to commit the generated Lua, you have a couple options:
Personally I don't mind just committing the generated Lua, you could even set up a pre commit hook to compile before committing. Anyway, you can find (incomplete) type definitions for Neovim's Lua api here in the teal-types repo if you do decide to use Teal. |
Beta Was this translation helpful? Give feedback.
-
What about using it for personal nvim configs? Is anyone using teal for that so I can take inspiration from them? I'm a bit tired of all the guess work while coding in Lua for neovim |
Beta Was this translation helpful? Give feedback.
tl.loader()
injects a 'searcher' function as described here in the Lua manual to search for.tl
files when usingrequire
and compiles them on the fly (without type checking them). As far as performance goes, I personally wouldn't recommend it for Neovim as it can increase your start up time quite a bit (obviously depending on how much code you are compiling).But as far as not wanting to commit the generated Lua, you have a couple options:
tl
orcyan
installed (which isn't a problem for packer, not sure if other managers have luarocks deps yet).