summaryrefslogtreecommitdiffstatshomepage
path: root/runtime/lua/vim/_editor.lua
AgeCommit message (Collapse)AuthorFiles
2025-12-30build: ship "_core/*" as bytecode (built-into Nvim binary)Justin M. Keyes1
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/`
2025-12-23fix(lua): separate vim.{g,b,w,t} types #37081phanium1
Problem: When `vim.g.foo = 1`, `vim.b.foo` also appears as a completion candidate (when use emmylua_ls). Solution: Define separate types.
2025-12-18fix(lua): don't remove first char of non-file stacktrace source (#37008)zeertzjq1
2025-11-20fix(input): discard following keys when discarding <Cmd>/K_LUA (#36498)zeertzjq1
Technically the current behavior does match documentation. However, the keys following <Cmd>/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 <Cmd>/K_LUA, but doing that may cause some performance problems, and even in that case the keys should still be discarded together.
2025-09-16fix(paste): don't use :echo immediately before :redraw (#35773)zeertzjq1
- 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.
2025-08-17feat(lua): `vim.pos`/`vim.range`Yi Ming1
2025-07-13feat(net): vim.net.request(), :edit [url] #34140Tom Ampuero1
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
2025-07-12fix(lua): vim.diff is nil in uv.new_work() thread #34909Justin M. Keyes1
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`).
2025-07-12refactor(lua): rename vim.diff => vim.text.diff #34864Justin M. Keyes1
Problem: `vim.diff()` was introduced before we had the `vim.text` module, where it obviously belongs. Solution: Move it.
2025-07-10docs: move vim.system to own sectionLewis Russell1
2025-07-04feat(pack): add built-in plugin manager `vim.pack`Evgeni Chasnovski1
Problem: No built-in plugin manager Solution: Add built-in plugin manager Co-authored-by: Lewis Russell <lewis6991@gmail.com>
2025-07-02fix(vim.system): env=nil passes env=nil to uv.spawnLewis Russell1
731e616a79 made it so passing `{env = nil, clear_env = true }` would pass `{env = {}}` to `vim.uv.spawn`. However this is not what `clear_env` is (arguably) supposed to do. If `env=nil` then that implies the uses wants `vim.uv.spawn()` to use the default environment. Adding `clear_env = true` simply prevents `NVIM` (the base environment) from being added. Fixes #34730
2025-06-13docs: vim.fs., diagnostics, lsp #34402Justin M. Keyes1
2025-06-07docs: lua, UI events #34261Justin M. Keyes1
2025-05-10refactor(docs): remove unnecessary `@private`/`@nodoc` annotations (#33951)Maria José Solano1
* refactor(docs): remove `@private` annotations from local functions * refactor(docs): remove unnecessary `@nodoc` annotations
2025-03-26fix(lua): no omni/cmdline completion for vim.env (#33044)Phạm Bình An1
Problem: - `:lua vim.env.<Tab>` does not show completion of environment variables - Meanwhile, `:let $<Tab>` does show completion of environment variables Solution: - Fix it
2025-03-24fix(cmdline): cmdline completion of _defer_require() modules #33007phanium1
Problem: `:lua vim.lsp.c<tab>` does not list vim.lsp.completion in the completion list after 24cea4c7f7417c7fe99a98a0487f51dd68c4f409. Solution: - Always include `vim.lsp._submodule` keys in candidates. - Fixes `vim.lsp.c<tab>` -> `vim.lsp.completion`. - Eager-load `vim.lsp.completion` to get its completion. - Fixes `vim.lsp.completion.g<tab>` -> `vim.lsp.completion.get`.
2025-03-23fix(paste): wrong '[ mark after pasting a big string (streamed chunks) #33025Au.1
Problem Pasting a big string ("streamed paste" with multiple chunks) sets the '[ mark to the edit from the last chunk, instead of the start of the paste. Solution: Set the '[ mark where the paste started, not where the last chunk was inserted. Note: `startpos == nil` is not equal to `phase == 1` because there may be some empty chunks pasted which won't arrive here (returned at code before).
2025-03-18docs: misc #32959Justin M. Keyes1
2025-03-07fix(lua): always use vim.inspect() for :lua= (#32715)zeertzjq1
2025-03-02feat(lua): don't complete private (_) fields after dot (.) #32690Maria José Solano1
2025-02-23fix(lua): `@private` => `@nodoc` #32587Dan Sully1
Problem: vim.log.levels.* and vim.opt_local are marked `@private` but they should be `@nodoc`. Solution: Fix the annotation.
2025-01-27fix: resolve all remaining LuaLS diagnosticsLewis Russell1
2025-01-11docs: miscdundargoc1
Co-authored-by: Axel <axelhjq@gmail.com> Co-authored-by: Colin Kennedy <colinvfx@gmail.com> Co-authored-by: Daiki Noda <sys9kdr@users.noreply.github.com> Co-authored-by: Evgeni Chasnovski <evgeni.chasnovski@gmail.com> Co-authored-by: Jean-Jacq du Plessis <1030058+jj-du-plessis@users.noreply.github.com> Co-authored-by: Juan Giordana <juangiordana@gmail.com> Co-authored-by: Lincoln Wallace <locnnil0@gmail.com> Co-authored-by: Matti Hellström <hellstrom@scm.com> Co-authored-by: Steven Locorotondo <steven.locorotondo@justeattakeaway.com> Co-authored-by: Yochem van Rosmalen <git@yochem.nl> Co-authored-by: glepnir <glephunter@gmail.com> Co-authored-by: ifish <fishioon@live.com>
2025-01-09docs: misc #31867Justin M. Keyes1
2025-01-09feat(api): deprecate nvim_out/err_write(ln)Luuk van Baal1
2024-11-17fix(messages): proper multiline Lua print() messages #31205luukvbaal1
Problem: Separate message emitted for each newline present in Lua print() arguments. Solution: Make msg_multiline() handle NUL bytes. Refactor print() to use msg_multiline(). Refactor vim.print() to use print().
2024-11-11perf(lsp): use faster version of str_byteindexLewis Russell1
2024-11-02fix(lua): show stacktrace for error in vim.on_key() callback (#31021)zeertzjq1
2024-11-01feat(lua): allow vim.on_key() callback to consume the key (#30939)errael1
2024-10-26refactor(lsp): drop str_byteindex/str_utfindex wrappers #30915Tristan Knight1
* deprecate old signatures * move to new str_byteindex/str_utfindex signature * use single-underscore name (double-underscore is reserved for Lua itself)
2024-10-23feat(stdlib): overload vim.str_byteindex, vim.str_utfindex #30735Tristan Knight1
PROBLEM: There are several limitations to vim.str_byteindex, vim.str_utfindex: 1. They throw given out-of-range indexes. An invalid (often user/lsp-provided) index doesn't feel exceptional and should be handled by the caller. `:help dev-error-patterns` suggests that `retval, errmsg` is the preferred way to handle this kind of failure. 2. They cannot accept an encoding. So LSP needs wrapper functions. #25272 3. The current signatures are not extensible. * Calling: The function currently uses a fairly opaque boolean value to indicate to identify the encoding. * Returns: The fact it can throw requires wrapping in pcall. 4. The current name doesn't follow suggestions in `:h dev-naming` and I think `get` would be suitable. SOLUTION: - Because these are performance-sensitive, don't introduce `opts`. - Introduce an "overload" that accepts `encoding:string` and `strict_indexing:bool` params. ```lua local col = vim.str_utfindex(line, encoding, [index, [no_out_of_range]]) ``` Support the old versions by dispatching on the type of argument 2, and deprecate that form. ```lua vim.str_utfindex(line) -- (utf-32 length, utf-16 length), deprecated vim.str_utfindex(line, index) -- (utf-32 index, utf-16 index), deprecated vim.str_utfindex(line, 'utf-16') -- utf-16 length vim.str_utfindex(line, 'utf-16', index) -- utf-16 index vim.str_utfindex(line, 'utf-16', math.huge) -- error: index out of range vim.str_utfindex(line, 'utf-16', math.huge, false) -- utf-16 length ```
2024-10-21feat(vim.validate): improve fast form and deprecate spec formLewis Russell1
Problem: `vim.validate()` takes two forms when it only needs one. Solution: - Teach the fast form all the features of the spec form. - Deprecate the spec form. - General optimizations for both forms. - Add a `message` argument which can be used alongside or in place of the `optional` argument.
2024-10-21refactor: rename vim.highlight => vim.hlJustin M. Keyes1
Problem: - `vim.highlight` module does not follow `:help dev-name-common`, which documents the name for "highlight" as "hl". - Shorter names are usually preferred. Solution: Rename `vim.highlight` to `vim.hl`. This is not a breaking change until 2.0 (or maybe never).
2024-10-21fix(lua): vim.deprecate does not support major>0Justin M. Keyes1
2024-10-17perf(validate): use lighter versionLewis Russell1
- Also fix `vim.validate()` for PUC Lua when showing errors for values that aren't string or number.
2024-10-12docs(lua): clarify when on_key "typed" will be empty (#30774)zeertzjq1
2024-10-12fix(lua): avoid recursive vim.on_key() callback (#30753)zeertzjq1
2024-10-04feat(lua): completion for vim.fn, vim.v, vim.o #30472Jongwook Choi1
Problem: Lua accessors for - global, local, and special variables (`vim.{g,t,w,b,v}.*`), and - options (`vim.{o,bo,wo,opt,opt_local,opt_global}.*`), do not have command-line completion, unlike their vimscript counterparts (e.g., `g:`, `b:`, `:set`, `:setlocal`, `:call <fn>`, etc.). Completion for vimscript functions (`vim.fn.*`) is incomplete and does not list all the available functions. Solution: Implement completion for vimscript function, variable and option accessors in `vim._expand_pat` through: - `getcompletion()` for variable and vimscript function accessors, and - `nvim_get_all_options_info()` for option accessors. Note/Remark: - Short names for options are yet to be implemented. - Completions for accessors with handles (e.g. `vim.b[0]`, `vim.wo[0]`) are also yet to be implemented, and are left as future work, which involves some refactoring of options. - For performance reasons, we may want to introduce caching for completing options, but this is not considered at this time since the number of the available options is not very big (only ~350) and Lua completion for option accessors appears to be pretty fast. - Can we have a more "general" framework for customizing completions? In the future, we may want to improve the implementation by moving the core logic for generating completion candidates to each accessor (or its metatable) or through some central interface, rather than writing all the accessor-specific completion implementations in a single function: `vim._expand_pat`.
2024-09-29docs: misc (#30177)dundargoc1
Co-authored-by: Christian Clason <c.clason@uni-graz.at> Co-authored-by: Riley Bruins <ribru17@hotmail.com> Co-authored-by: zeertzjq <zeertzjq@outlook.com>
2024-09-24docs: lua error patterns #30240Justin M. Keyes1
Co-authored-by: Mathias Fussenegger <f.mathias@zignar.net> Co-authored-by: Ananth Bhaskararaman <antsub@gmail.com>
2024-09-01docs: misc #28970Justin M. Keyes1
2024-06-07docs: misc (#28837)dundargoc1
Co-authored-by: Danymat <d.danymat@gmail.com> Co-authored-by: Gregory Anders <greg@gpanders.com> Co-authored-by: Jakub Okoński <jakub@okonski.org> Co-authored-by: John L. Villalovos <john@sodarock.com> Co-authored-by: Maria José Solano <majosolano99@gmail.com> Co-authored-by: Michaili K <git@michaili.dev> Co-authored-by: TheLeoP <eugenio2305@hotmail.com> Co-authored-by: Tobias Schmitz <tobiasschmitz2001@gmail.com> Co-authored-by: W20MC <157727813+W20MC@users.noreply.github.com> Co-authored-by: Will Hopkins <willothyh@gmail.com> Co-authored-by: Yifan Hu <141280278+b0ae989c@users.noreply.github.com> Co-authored-by: glepnir <glephunter@gmail.com> Co-authored-by: prljav <74116121+prljav@users.noreply.github.com>
2024-05-28refactor: deprecate vim.region() #28416Justin M. Keyes1
Problem: `vim.region()` is redundant with `getregionpos()`. Solution: Deprecate `vim.region()`.
2024-05-24fix: change deprecation presentationdundargoc1
Deprecation with vim.deprecate is currently too noisy. Show the following warning instead: [function] is deprecated. Run ":checkhealth vim.deprecated" for more information. The important part is that the full message needs to be short enough to fit in one line in order to not trigger the "Press ENTER or type command to continue" prompt. The full information and stack trace for the deprecated functions will be shown in the new healthcheck `vim.deprecated`.
2024-04-23perf(lua): faster vim.deprecate() #28470Evgeni Chasnovski1
Problem: `vim.deprecate()` can be relatively significantly slower than the deprecated function in "Nvim" plugin. Solution: Optimize checks for "Nvim" plugin. This also results into not distinguishing "xxx-dev" and "xxx" versions when doing checks, which is essentially covered by the deprecation logic itself. With this rewrite I get the times from #28459: `{ 0.024827, 0.003797, 0.002024, 0.001774, 0.001703 }`. For quicker reference: - On current Nightly it is something like `{ 3.72243, 0.918169, 0.968143, 0.763256, 0.783424 }`. - On 0.9.5: `{ 0.002955, 0.000361, 0.000281, 0.000251, 0.00019 }`.
2024-04-18feat(lua): enable(enable:boolean, filter:table) #28374Justin M. Keyes1
Problem: We need to establish a pattern for `enable()`. Solution: - First `enable()` parameter is always `enable:boolean`. - Update `vim.diagnostic.enable()` - Update `vim.lsp.inlay_hint.enable()`. - It was not released yet, so no deprecation is needed. But to help HEAD users, it will show an informative error. - vim.deprecate(): - Improve message when the "removal version" is a *current or older* version.
2024-04-15fix(vim.ui): open() may wait indefinitely #28325Justin M. Keyes1
Problem: vim.ui.open "locks up" Nvim if the spawned process does not terminate. #27986 Solution: - Change `vim.ui.open()`: - Do not call `wait()`. - Return a `SystemObj`. The caller can decide if it wants to `wait()`. - Change `gx` to `wait()` only a short time. - Allows `gx` to show a message if the command fails, without the risk of waiting forever.
2024-03-31feat(lua): pass keys before mapping to vim.on_key() callback (#28098)zeertzjq1
Keys before mapping (i.e. typed keys) are passed as the second argument.
2024-03-10docs(editorconfig): move to sourceLewis Russell1