summaryrefslogtreecommitdiffstatshomepage
path: root/test/functional/vimscript/executable_spec.lua
diff options
context:
space:
mode:
authorJustin M. Keyes <justinkz@gmail.com>2026-04-17 19:10:20 -0400
committerGitHub <noreply@github.com>2026-04-17 19:10:20 -0400
commit0d4d285bd2c19697164175280b32bf93e3a7b1da (patch)
tree0aa20f3e342279e9cba36e5c8daa0d38b2507c8d /test/functional/vimscript/executable_spec.lua
parent03193e2963a6f9333afc3090ad2c8002b648fe11 (diff)
perf(vim.fn): call Lua-implemented vim.fn.xx() directly #39166
Problem: - Builtin "Vimscript" functions (f_xx) are mostly implemented in C. Partly that's because there is some boilerplate required to call out to Lua. - Calls to `vim.fn.foo()` always marshall over the Lua <=> Vimscript ("typval") bridge, even if `fn.foo()` is implemented entirely in Lua: ``` Lua => typval => Object => Lua => Object => typval => Lua. ``` Solution: Functions declared in eval.lua with `func_lua` are implemented in entirely in Lua (`_core/vimfn.lua`). - `gen_eval.lua` wires `func_lua` entries to `lua_wrapper`, which handles the typval conversion for Vimscript callers (slow path). - `nlua_call()` detects `func_lua` functions and calls the Lua implementation directly. This eliminates all conversion overhead for Lua callers (fast path). - Validate at build-time that `func`, `func_float`, and `func_lua` are mutually exclusive. - Migrate `hostname()` as a toy example, to show the idea.
Diffstat (limited to 'test/functional/vimscript/executable_spec.lua')
0 files changed, 0 insertions, 0 deletions