neovim/runtime/lua/vim/_editor.lua, branch master

build: ship "_core/*" as bytecode (built-into Nvim binary)

2025-12-30T06:44:24Z

Problem: We want to encourage implementing core features in Lua instead of C, but it's clumsy because: - Core Lua code (built into `nvim` so it is available even if VIMRUNTIME is missing/invalid) requires manually updating CMakeLists.txt, or stuffing it into `_editor.lua`. - Core Lua modules are not organized similar to C modules, `_editor.lua` is getting too big. Solution: - Introduce `_core/` where core Lua code can live. All Lua modules added there will automatically be included as bytecode in the `nvim` binary. - Move these core modules into `_core/*`: ``` _defaults.lua _editor.lua _options.lua _system.lua shared.lua ``` TODO: - Move `_extui/ => _core/ui2/`

fix(lua): separate vim.{g,b,w,t} types #37081

2025-12-23T15:39:22Z

Problem: When `vim.g.foo = 1`, `vim.b.foo` also appears as a completion candidate (when use emmylua_ls). Solution: Define separate types.

fix(lua): don't remove first char of non-file stacktrace source (#37008)

2025-12-18T00:09:16Z

fix(input): discard following keys when discarding /K_LUA (#36498)

2025-11-20T04:33:02Z

Technically the current behavior does match documentation. However, the keys following /K_LUA aren't normally received by vim.on_key() callbacks either, so it does makes sense to discard them along with the preceding key. One may also argue that vim.on_key() callbacks should instead receive the following keys together with the /K_LUA, but doing that may cause some performance problems, and even in that case the keys should still be discarded together.

fix(paste): don't use :echo immediately before :redraw (#35773)

2025-09-15T22:06:02Z

- If tick == 0 at the last chunk, the first :echo will print an empty string, which isn't really helpful, and may cause :redraw to move cursor to the message area for 'showmode'. - If tick > 0 at the last chunk, there'll be another :echo that prints an empty string immediately after the :redraw.

feat(lua): `vim.pos`/`vim.range`

2025-08-17T03:54:53Z

feat(net): vim.net.request(), :edit [url] #34140

2025-07-13T20:43:11Z

Problem: Nvim depends on netrw to download/request URL contents. Solution: - Add `vim.net.request()` as a thin curl wrapper: - Basic GET with --silent, --show-error, --fail, --location, --retry - Optional `opts.outpath` to save to a file - Operates asynchronously. Pass an `on_response` handler to get the result. - Add integ tests (requires NVIM_TEST_INTEG to be set) to test success and 404 failure. - Health check for missing `curl`. - Handle `:edit https://…` using `vim.net.request()`. API Usage: 1. Asynchronous request: vim.net.request('https://httpbingo.org/get', { retry = 2 }, function(err, response) if err then print('Fetch failed:', err) else print('Got body of length:', #response.body) end end) 2. Download to file: vim.net.request('https://httpbingo.org/get', { outpath = 'out_async.txt' }, function(err) if err then print('Error:', err) end end) 3. Remote :edit integration (in runtime/plugin/net.lua) fetches into buffer: :edit https://httpbingo.org/get

fix(lua): vim.diff is nil in uv.new_work() thread #34909

2025-07-13T03:54:22Z

Problem: The "gitsigns" plugin runs `vim.diff` in a thread (`uv.new_work`), but `vim.diff` is nil in that context: Lua callback: …/gitsigns.nvim/lua/gitsigns/diff_int.lua:30: bad argument #1 to 'decode' (string expected, got nil) stack traceback: [C]: in function 'decode' …/gitsigns.nvim/lua/gitsigns/diff_int.lua:30: in function <…/gitsigns.nvim/lua/gitsigns/diff_int.lua:29> Luv thread: …/gitsigns.nvim/lua/gitsigns/diff_int.lua:63: attempt to call field 'diff' (a nil value) Solution: Revert the `stdlib.c` change (set `vim.diff` instead of `vim._diff`).

refactor(lua): rename vim.diff => vim.text.diff #34864

2025-07-12T22:36:07Z

Problem: `vim.diff()` was introduced before we had the `vim.text` module, where it obviously belongs. Solution: Move it.

docs: move vim.system to own section

2025-07-10T12:34:58Z