aboutsummaryrefslogtreecommitdiff
path: root/runtime/doc/lua.txt
Commit message (Collapse)AuthorAge
...
* docs: misc #38532Justin M. Keyes2026-03-29
| | | | | | | | | Close #38431 Close #38521 Close #38530 Co-authored-by: tayheau <thopsore@pasteur.fr> Co-authored-by: zeertzjq <zeertzjq@outlook.com> Co-authored-by: Olivia Kinnear <git@superatomic.dev>
* feat: extend vim.Pos, vim.Range #36397Luis Calle2026-03-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Using nested `vim.Pos` objects to represent each `vim.Range` object requires 3 tables for each `vim.Range`, which may be undesirable in performance critical code. Using key-value tables performs worse than using array-like tables (lists). Solution: Use array-like indices for the internal fields of both `vim.Pos` and `vim.Range` objects. Use a metatable to allow users to access them like if they were key-value tables. --- Problem: The `vim.Pos` conversion interface for `extmark` indexing does not take into account the difference in how a position on top of a newline is represented in `vim.Pos` and `extmark`. - `vim.Pos`: for a newline at the end of row `n`, `row` takes the value `n + 1` and `col` takes the value `0`. - `extmark`: for a newline at the end of for `n`, `row` takes the value `n` and `col` takes the value `#row_text`. Solution: Handle this in the `extmark` interface. --- Problem: Not all `to_xxx` interfaces have wrapping objects like `to_lsp`. Solution: Return unwrapped values in `to_xxx` interfaces where it makes sense. Accept unwrapped values in "from" interfaces where it makes sense. --- Problem: `start` and `end` positions have different semantics, so they can't be compared. `vim.Range` relies on comparing the `end` and `start` of two ranges to decide which one is greater, which doesn't work as expected because this of the different semantics. For example, for the ranges: local a = { start = { row = 0, col = 22, }, end_ = { row = 0, col = 24, }, } local b = { start = { row = 0, col = 17, }, end_ = { row = 0, col = 22, }, } in this code: local foo, bar = "foo", "bar" -- |---||-| -- b a The range `b` is smaller than the range `a`, but the current implementation compares `b._end` (`col = 22`) and `a.start` (`col = 22`) and concludes that, since `b.col` is not smaller than `a.col`, `b` should be greater than `a`. Solution: - Use a `to_inclusive_pos` to normalize end positions inside of `vim.Range` whenever a comparison between a start and an end position is necessary.
* docs: news #38464Justin M. Keyes2026-03-28
|
* fix(ui2): ENTER may focus pager in insert/terminal mode #38497phanium2026-03-26
| | | | | | | fix(ui2): prevent <CR> from focusing pager in insert/terminal mode Problem: <CR> in insert/terminal mode can focus pager unexpectedly. Solution: Don't enter the pager when <CR> is pressed during expanded cmdline in insert/terminal mode.
* docs: api, plugins, ui2Justin M. Keyes2026-03-24
|
* feat(net): vim.net.request(outbuf) writes response to buffer #36164Yochem van Rosmalen2026-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Non-trivial to write output of vim.net.request to buffer. Requires extra code in plugin/net.lua which can't be reused by other plugin authors. ``` vim.net.request('https://neovim.io', {}, function(err, res) if not err then local buf = vim.api.nvim_create_buf(true, false) if res then local lines = vim.split(res.body, '\n', { plain = true }) vim.api.nvim_buf_set_lines(buf, 0, -1, true, lines) end end end) ``` Solution: Accept an optional `outbuf` argument to indicate the buffer to write output to, similar to `outpath`. vim.net.request('https://neovim.io', { outbuf = buf }) Other fixes / followups: - Make plugin/net.lua smaller - Return objection with close() method - vim.net.request.Opts class - vim.validate single calls - Use (''):format(...) instead of `..`
* fix(lua): drop support for boolean `buf` in `vim.keymap` #38432skewb1k2026-03-23
| | | | | | | | | | | Problem: `vim.keymap.*.Opts.buf` allows `boolean` aliases for more widely used `integer?` values, `true` -> `0` and `false` -> `nil`. This conversion is unnecessary and can be handled at call sites. Solution: As a follow-up to deprecating the `buffer` option, drop support for boolean values for the new `buf` option. The deprecated `buffer` continues to support booleans for backward compatibility.
* docs: starting.txt new layoutJustin M. Keyes2026-03-22
|
* feat(lua): replace `buffer` with `buf` in vim.keymap.set/del #38360skewb1k2026-03-21
| | | | | | The `buffer` option remains functional but is now undocumented. Providing both will raise an error. Since providing `buf` was disallowed before, there is no code that will break due to using `buffer` alongside `buf`.
* feat(ui2): configure maximum window heights #38392luukvbaal2026-03-21
| | | | | | | | | | | | | | | | | | | Problem: - Window height is set dynamically to match the text height, making it difficult for the user to use a different height. - Cmdwin is closed to enter the pager but still taken into account for the pager position, and not restored when the pager is closed. - Dialog pager handler may unnecessarily consume <Esc>. Solution: - Add maximum height config fields for each of the UI2 windows, where a number smaller than one is a fraction of 'lines', absolute height otherwise (i.e. `cfg.msg.pager.height = 0.5`). - If the cmdwin will be closed to enter the pager, don't try to position the pager above it. Re-enter the cmdwin when the pager is closed. - Only add vim.on_key() handler for the dialog paging is actually possible.
* docs: miscJustin M. Keyes2026-03-20
|
* feat(progress): status api, 'statusline' integration #35428Shadman2026-03-20
| | | | | | | | | | | | | | Problem: Default statusline doesn't show progress status. Solution: - Provide `vim.ui.progress_status()`. - Include it in the default 'statusline'. How it works: Status text summarizes "running" progress messages. - If none: returns empty string - If one running item: "title: percent%" - If multiple running items: "Progress: N items avg-percent%"
* feat(stdlib): vim.fs.ext() returns file extension #36997Yochem van Rosmalen2026-03-20
| | | | | | | | | | | | | | | | | Problem: Checking the extension of a file is done often, e.g. in Nvim's codebase for differentiating Lua and Vimscript files in the runtime. The current way to do this in Lua is (1) a Lua pattern match, which has pitfalls such as not considering filenames starting with a dot, or (2) fnamemodify() which is both hard to discover and hard to use / read if not very familiar with the possible modifiers. vim.fs.ext() returns the file extension including the leading dot of the extension. Similar to the "file extension" implementation of many other stdlibs (including fnamemodify(file, ":e")), a leading dot doesn't indicate the start of the extension. E.g.: the .git folder in a repository doesn't have the extension .git, but it simply has no extension, similar to a folder named git or any other filename without dot(s).
* docs: miscJustin M. Keyes2026-03-13
|
* docs: deprecate hit-enterJustin M. Keyes2026-03-11
|
* docs: api, messages, lsp, trustJustin M. Keyes2026-03-11
| | | | | gen_vimdoc.lua: In prepare for the upcoming release, comment-out the "Experimental" warning for prerelease features.
* feat(ui2): support routing "typed_cmd" trigger to targetLuuk van Baal2026-03-04
| | | | | | Problem: Unable to immediately open a typed command in the pager. Solution: Support mapping msg_show "typed_cmd" trigger in cfg.msg.targets (e.g. `targets = { typed_cmd = 'pager' }`).
* feat(ui2): configure targets per message kind #38091luukvbaal2026-02-28
| | | | | | | | | Problem: Unable to configure message targets based on message kind. Solution: Add cfg.msg.targets mapping message kinds to "cmd/msg/pager". Check the configured target when writing the message. cfg.msg = { target = 'cmd', targets = { progress = 'msg', list_cmd = 'pager' } } will for example use the 'msg' target for progress messages, immediately open the pager for 'list_cmd' and use the cmdline for all other message kinds.
* fix(vim.fs): joinpath() should ignore empty items #38077Yochem van Rosmalen2026-02-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: vim.fs.joinpath treats empty string as a path segment (it adds a path separator for each empty item): print(vim.fs.joinpath('', 'after/lsp', '')) -- '/after/lsp/' print(vim.fs.joinpath('', '')) -- '/' Especially problematic if the empty segment is the first segment, as that converts the path to an absolute path. Solution: Ignore empty (length of 0) path segments. Benchmark: local function test(func) local t = vim.uv.hrtime() for _ = 1, 100000, 1 do func('', 'this/is', 'a/very/long/path', '', 'it', 'really', 'is') end print(math.floor((vim.uv.hrtime() - t) / 1e6), 'ms') end - with Iter():filter() --> 370 ms - building new segments table --> 208 ms - with vim.tbl_filter --> 232 ms - Instead of gsub split on `/` in all parts --> 1870 ms
* feat(secure): allow 'path' parameter for trust action 'allow' (#38001)anondeveg2026-02-25
|
* feat(messages): drop hardcoded 'showmode' delay #38029Justin M. Keyes2026-02-23
| | | | | | | | Problem: - Editing a 'readonly' file forces a 3-second delay. - nvim_get_mode waits 3 secs with 'showmode' enabled or when there are error messages. Solution: Remove the delay for "ui2", by using `msg_delay`.
* refactor: defer_fn return type #37999Justin M. Keyes2026-02-23
|
* feat(lua): support vim.Range:has(vim.pos) #37879Maria Solano2026-02-16
|
* docs: Lua error codes E970, E5107-E5116 #37577glepnir2026-02-14
|
* docs(lua): correct vim.wait() interval description (#37856)zeertzjq2026-02-14
| | | Use the wording from the wait() Vimscript function.
* feat(iter): peek(), skip(predicate) for non-list iterators #37604Elijah Koulaxis2026-02-12
| | | | | | | | | | | | Problem: Iter:peek() only works if the iterator is a |list-iterator| (internally, an `ArrayIter`). However, it is possible to implement :peek() support for any iterator. Solution: - add `_peeked` buffer for lookahead without actually consuming values - `peek()` now works for function, pairs(), and array iterators - `skip(predicate)` stops at the first non matching element without consuming it - keep existing optimized behavior for `ArrayIter` to maintain backward compatibility - use `pack`/`unpack` to support iterators that return multiple values
* docs: vim.fs path expansionJustin M. Keyes2026-02-12
| | | | fix #37583
* feat(stdlib): vim.json.decode() can allow comments #37795skewb1k2026-02-11
| | | | | | | | | Problem: `vim.json.decode()` could not parse JSONC (JSON with Comments) extension, which is commonly used in configuration files. Solution: Introduce an `skip_comments` option, which is disabled by default. When enabled, allows JavaScript-style comments within JSON data.
* feat(lua): add `Iter:unique()` (#37592)Olivia Kinnear2026-02-10
|
* fix(vim.fs): make `rm()` work with symlink to a directoryEvgeni Chasnovski2026-02-10
|
* docs(lua): vim.keymap.set takes no `noremap` #37723Christian Clason2026-02-05
| | | | | | | Problem: Unlike `nvim_keymap_set`, `vim.keymap.set` uses the non-negated `remap` instead of `:set`'s `noremap`, but the documentation for this got lost sometime before Nvim 0.10. Solution: Restore the lost documentation and make it more explicit.
* refactor: rename _extui => _core.ui2 #37692luukvbaal2026-02-05
| | | | | | | Problem: _extui module name is confusing and should eventually end up in _core/. Solution: Move it there and name it ui2.
* fix(lua): close vim.defer_fn() timer if vim.schedule() failed (#37647)zeertzjq2026-02-01
| | | | | | | | Problem: Using vim.defer_fn() just before Nvim exit leaks luv handles. Solution: Make vim.schedule() return an error message if scheduling failed. Make vim.defer_fn() close timer if vim.schedule() failed.
* fix: misc typos #37471phanium2026-01-27
|
* fix(ui): only internal messages are unsafe #37462luukvbaal2026-01-26
| | | | | | | | Problem: Fast context for msg_show event inhibits vim.ui_attach from displaying a stream of messages from a single command. Solution: Remove fast context from msg_show events emitted as a result of explicit API/command calls. The fast context was originally introduced to prevent issues with internal messages.
* docs(lua): iInconsistent vim.keymap param name #37026Bryan Turns2025-12-20
| | | | | | | | Problem: vim.keymap.del has 'modes' as it's first argument while vim.keymap.set has 'mode' as it's first argument despite both 'mode' and 'modes' taking in the same type input of String or String[]. Solution: Updated vim.keymap.set docs to refer to it's first argument as 'modes'.
* fix(lua): don't remove first char of non-file stacktrace source (#37008)zeertzjq2025-12-18
|
* docs: misc, editorconfigJustin M. Keyes2025-12-15
| | | | fix https://github.com/neovim/neovim/issues/36858
* fix(lua): relax `vim.wait()` timeout validation #36900skewb1k2025-12-10
| | | | | | | | | Problem: After bc0635a9fc9c15a2423d4eb35f627d127d00fa46 `vim.wait()` rejects floats and NaN values. Solution: Restore the prior behavior, while still supporting `math.huge`. Update tests to cover float case.
* fix(input): discard following keys when discarding <Cmd>/K_LUA (#36498)zeertzjq2025-11-20
| | | | | | | | | | | 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.
* docs: misc #36580Justin M. Keyes2025-11-16
| | | | | | | | Co-authored-by: nguyenkd27 <nguyenkd27@gmail.com> Co-authored-by: dundargoc <gocdundar@gmail.com> Co-authored-by: Yochem van Rosmalen <git@yochem.nl> Co-authored-by: Tuure Piitulainen <tuure.piitulainen@gmail.com> Co-authored-by: Maria Solano <majosolano99@gmail.com> Co-authored-by: tao <2471314@gmail.com>
* docs: getpos, getregion, lspJustin M. Keyes2025-11-15
|
* fix(lsp): don't overlay insertion-style inline completions (#36477)Riley Bruins2025-11-09
| | | | | | | | | | | | | | | * feat(lua): `Range:is_empty()` to check vim.range emptiness * fix(lsp): don't overlay insertion-style inline completions **Problem:** Some servers commonly respond with an empty inline completion range which acts as a position where text should be inserted. However, the inline completion module assumes that all responses with a range are deletions + insertions that thus require an `overlay` display style. This causes an incorrect preview, because the virtual text should have the `inline` display style (to reflect that this is purely an insertion). **Solution:** Only use `overlay` for non-empty replacement ranges.
* docs: regenerate lua.txt (#36376)zeertzjq2025-10-29
|
* fix(filetype): move fallback logic to vim.filetype.match() #30141Jonny Kong2025-10-28
| | | | | | | | | | | | Problem: Previously, the fallback logic to ".conf" was located outside of `vim.filetype.match()` and directly within the AutoCmd definition. As a result, `vim.filetype.match()` would return nil instead of ".conf" for fallback cases (#30100). Solution: Added a boolean return value to `vim.filetype.match()` that indicates whether the match was the result of fallback. If true, the filetype will be set using `setf FALLBACK <ft>` instead of `setf <ft>`.
* docs: types, news, lua-pluginJustin M. Keyes2025-10-24
| | | | | | - mention "lua_ls", not "luals". https://github.com/neovim/neovim/discussions/36182 Co-authored-by: Maria Solano <majosolano99@gmail.com>
* docs: small fixes (#36146)zeertzjq2025-10-12
| | | | | | | | | Close #35989 Close #36031 Close #36107 Co-authored-by: Kieran Moy <kfatyuip@gmail.com> Co-authored-by: William Sprent <william@sprent.dk> Co-authored-by: David Briscoe <43559+idbrii@users.noreply.github.com>
* fix(docs): force blank line after numbered list items #35950Maria Solano2025-09-28
| | | | Workaround until the vimdoc parser supports numbered list-items: https://github.com/neovim/tree-sitter-vimdoc/issues/144
* docs: json, tests, lsp #35754Justin M. Keyes2025-09-28
| | | | | | | Close #35926 Close #35818 Co-authored-by: skewb1k <skewb1kunix@gmail.com> Co-authored-by: glepnir <glephunter@gmail.com>
* docs: small fixes (#35791)zeertzjq2025-09-16
| | | | | | | | | | | | | | | | | | | | | Close #34938 Close #35030 Close #35233 Close #35259 Close #35290 Close #35433 Close #35541 Close #35766 Close #35792 Co-authored-by: huylg <45591413+huylg@users.noreply.github.com> Co-authored-by: Jason Del Ponte <961963+jasdel@users.noreply.github.com> Co-authored-by: sooriya <74165167+thuvasooriya@users.noreply.github.com> Co-authored-by: Andrew Braxton <andrewcbraxton@gmail.com> Co-authored-by: Enric Calabuig <enric.calabuig@gmail.com> Co-authored-by: Augusto César Dias <augusto.c.dias@gmail.com> Co-authored-by: David Sierra DiazGranados <davidsierradz@gmail.com> Co-authored-by: Stepan Nikitin <90522882+vectravox@users.noreply.github.com> Co-authored-by: Emilien Breton <bricktech2000@gmail.com>