neovim/src/nvim/lua/executor.c, branch master

fix(lua): don't strip debuginfo in precompile module #39191

2026-04-23T16:42:41Z

Problem: debug.getinfo on bytecode module/func don't give you detail source info. Solution: - Use `loadstring`+`string.dump` to replace LUAC_PRG(`luac`/`luajit -b`) - `string.dump(…,false)` to generate non-strip version bytecode - `loadstring(…,fname)` to specify the full source name BEFORE: $ nvim --clean +'=debug.getinfo(vim.fn.maparg("]", "n", 0, 1).callback, "Sl")' --headless +q { currentline = -1, lastlinedefined = 456, linedefined = 452, short_src = "?", source = "=?", what = "Lua" } AFTER: $ nvim --clean +'=debug.getinfo(vim.fn.maparg("]", "n", 0, 1).callback, "Sl")' --headless +q { currentline = -1, lastlinedefined = 456, linedefined = 452, short_src = "/home/xx/b/neovim/runtime/lua/vim/_core/defaults.lua", source = "@/home/xx/b/neovim/runtime/lua/vim/_core/defaults.lua", what = "Lua" }

feat(eval): treat Lua string as "blob" in writefile() #39098

2026-04-22T17:36:43Z

Problem: vim.fn.writefile() treats Lua strings as Vimscript strings instead of a "binary clean" string. Solution: Treat Lua-originated strings as blob data.

fix(excmd): nlua_call_excmd require() failure is a "lua_error"

2026-04-20T00:31:09Z

Although `nlua_call_excmd` is semantically for implementing Ex-commands, the `require()` should never fail, so that's a "Lua error". But if the call itself fails (the later `semsg` call), that's an "Ex cmd" error.

refactor(excmd): migrate ex_terminal to Lua

2026-04-20T00:31:09Z

refactor(excmd): migrate ex_checkhealth to Lua

2026-04-20T00:12:05Z

feat(vimfn): use Lua for more excmds/vimfns

2026-04-18T14:57:37Z

Problem: Too much boilerplate needed to use Lua to impl an excmd or f_xx function. Solution: - Add `nlua_call_vimfn` which takes the args typval, executes Lua, and returns a typval. - refactor(excmd): lua impl for :log, :lsp

perf(vim.fn): call Lua-implemented vim.fn.xx() directly #39166

2026-04-17T23:10:20Z

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.

docs: news #38464

2026-03-28T13:59:54Z

fix(messages): disallow user-defined integer message-id #38359

2026-03-19T01:07:17Z

Problem: `nvim_echo(…, {id=…})` accepts user-defined id as a string or integer. Generated ids are always higher than last highest msg-id used. Thus plugins may accidentally advance the integer id "address space", which, at minimum, could lead to confusion when troubleshooting, or in the worst case, could overflow or "exhaust" the id address space. There's no use-case for it, and it could be the mildly confusing, so we should just disallow it. Solution: Disallow *integer* user-defined message-id. Only allow *string* user-defined message-id.

docs: api, messages, lsp, trust

2026-03-11T17:00:18Z

gen_vimdoc.lua: In prepare for the upcoming release, comment-out the "Experimental" warning for prerelease features.