aboutsummaryrefslogtreecommitdiff
path: root/runtime/lua
Commit message (Collapse)AuthorAge
...
* fix(vim.hl): range(0,…) highlight not cleared after buffer-switch #40130Justin M. Keyes2026-06-06
| | | | | | | | | | Problem: When `vim.hl.range(0, …, { timeout = N })` is called, the deferred `range_hl_clear` captures `buf=0`, which resolves to an arbitrary "current buffer" at timeout. This may cause a stale highlight that never gets cleared. Solution: Resolve `buf=0` explicitly, before `range_hl_clear` captures it.
* fix(option): allow empty/blank edges in 'winborder' #40112glepnir2026-06-05
| | | | | | | | | | Problem: The comma form of 'winborder' is split with copy_option_part(), whose skip_to_option_part() eats spaces after a comma, and empty fields are rejected. Solution: Split the comma form literally on ',', keeping empty fields and single-space fields.
* fix(lsp): always respond to requests, even on handler error #40076Yi Ming2026-06-04
| | | | | | | | | Problem: We perform validations after the request handler is called. When these validations fail, `error()` and `assert()` will prevent the subsequent code from running, meaning the server will never receive a response. Solution: Always respond to requests.
* Merge #40088 from justinmk/doc2Justin M. Keyes2026-06-03
|\ | | | | docs: misc, lsp
| * docs: misc, lspJustin M. Keyes2026-06-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: This doc on `vim.lsp.completion.get()`: --- Used by the default LSP |omnicompletion| provider |vim.lsp.omnifunc()|, thus |i_CTRL-X_CTRL-O| --- invokes this in LSP-enabled buffers. Use CTRL-Y to select an item from the completion menu. --- |complete_CTRL-Y| ...makes two wrong claims: 1. "Used by the default LSP omnicompletion provider vim.lsp.omnifunc()" - `_omnifunc` does not call `M.get()`, it calls the internal `trigger()` directly. 2. "thus |i_CTRL-X_CTRL-O| invokes this in LSP-enabled buffers" - The two paths use different client sets: - `M.get()` reads `buf_handles[bufnr].clients` (clients explicitly registered via `vim.lsp.completion.enable(true, ...)`). - `_omnifunc` reads `lsp.get_clients({method='textDocument/completion'})` (every completion client, regardless of `enable()`). Solution: Update docs. Co-authored-by: Koichi Shiraishi <zchee.io@gmail.com> Co-authored-by: y9san9 / Alex Sokol <y9san9@gmail.com> Co-authored-by: adv0r <>
* | vim-patch:9.2.0589: filetype: xinitrc files are not recognized (#40102)zeertzjq2026-06-03
|/ | | | | | | | | | | | | | Problem: filetype: xinitrc files are not recognized Solution: Detect xinitrc and xserverrc files as sh filetype (Enrico Maria De Angelis) Reference: https://wiki.archlinux.org/title/Xinit#Configuration closes: vim/vim#20419 https://github.com/vim/vim/commit/5b76ddcc5220603b9c062d3e230faad9b0aed0d2 Co-authored-by: Enrico Maria De Angelis <enricomaria.dean6elis@gmail.com>
* fix(diagnostic): stack _tags hl-groups in a single extmark #38654Artem Krinitsyn2026-06-02
| | | | | | | | | | | | Problem: Diagnostic highlight groups were applied by iterating and calling `vim.hl.range` for each group individually. That resulted in multiple extmarks with the same priority being created separately, which does not allow `DiagnosticUnnecessary` and `DiagnosticDeprecated` with matching options override `Diagnostic*` styling. Solution: Pass the list of hl-groups to `vim.hl.range` so they are applied together in the correct order.
* fix(lsp): handle requests with null id #40073Yi Ming2026-06-02
| | | | | | | | | | | | | Problem: PR #38340 prevented messages we receive with id:null from being incorrectly classified as notifications, but caused us to ignore all messages with id:null, including requests. Solution: Handle requests with id:null. When we receive a request, we only need to respond based on the `method` and `param`. (The original so-called `notification_received` in the test was actually semantically `request_or_notification_received`.)
* Merge #40083 from ofseed/pos-get-lines-improveJustin M. Keyes2026-06-02
|\ | | | | fix(pos): various improvements on `pos._util.get_lines()`
| * fix(pos): `get_lines()` return empty table when file opening failsYi Ming2026-06-02
| | | | | | | | | | | | | | | | | | | | | | | | Problem: `get_lines()` may returns empty table when file opening fails, so every existing caller use `get_line() or ''` to avoid nil result. This also does not match the annotated return type of `get_line()`, which is `string` instead of `string?`. Solution: Make `get_line()` return empty string when file opening fails.
| * fix(pos): `get_lines()` never correctly fallbacks to empty stringYi Ming2026-06-02
| | | | | | | | | | | | | | | | | | Problem: `nvim_buf_get_lines` will always returns a table, so the `or` operator will never be used, letting `lines[row]` may be `nil` Solution: Fix it.
| * refactor(pos): remove unnecessary code of `get_lines()`, tidy upYi Ming2026-06-02
| | | | | | | | | | | | | | | | | | | | Problem: `get_lines()` actually supports passing a `integer` instead of `integer[]`, but it is never used in this way, we use `get_line()` instead. Solution: Fix it. Also rename some variables to align with our current naming convention and use `vim.fn.readblob()` instead of a bunch of `uv` calls.
* | Merge #40057 from luukvbaal/hidenodrawJustin M. Keyes2026-06-02
|\ \ | | | | | | perf(redraw): don't redraw hidden windows
| * | perf(redraw): don't redraw hidden windowsLuuk van Baal2026-05-31
| | | | | | | | | | | | | | | Problem: Hidden windows are redrawn unnecessarily. Solution: If a window is hidden, don't bother drawing it.
* | | refactor(net): parameterize transport logging #40022Yi Ming2026-06-02
| | |
* | | build(zig): run oldtests in zig builds with new lua runnerbfredl2026-06-02
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new lua based runner replaces Makefile, runnvim.sh and runnvim.vim As it happens, we run a `--headless` nvim inside a `:terminal` layer, this is pointless. Also there is still a lot remnants for oldesttests, but we don't have any except for test1.in which just checks the environment for following, nonexistant oldesttests. so just skip that. For now, the actual vimscript code which runs in vim-under-test is completely unchanged. On macos, luajit is finally working with the latest ziglua master. Also fix some minor bugs regarding locales, such as incorrect HAVE_WORKING_LIBINTL checks
* | vim-patch:partial:9.2.0573: Vim9: missing EX_WHOLE on some block keywords ↵zeertzjq2026-06-01
|/ | | | | | | | | | | | | | | | | | | | | | | (#40071) Problem: Several Vim9 keywords lack EX_WHOLE and can be shortened in Vim9 script, inconsistent with endif/enddef/endfor/endwhile/ endtry which already have it. The error from :endd in a nested function also hardcodes "enddef" instead of reporting what the user typed. fullcommand("ho") returns "horizontal" even though :ho is below the documented 3-char minimum. Solution: Add EX_WHOLE to :class, :def, :endclass, :endinterface, :endenum, :public and :static. In get_function_body() pass the user-typed command to the error message. Force :ho to CMD_SIZE in find_ex_command() so fullcommand() reflects the modifier minimum. Extend tests and documentation accordingly (Peter Kenny). fixes: vim/vim#20032 closes: vim/vim#20191 https://github.com/vim/vim/commit/38d9a16eba8cdf3377e8b867da805bf369454108 Co-authored-by: Peter Kenny <github.com@k1w1.cyou>
* docs: misc, options, pos/rangeJustin M. Keyes2026-05-30
|
* fix(health): sort "Active Features" by nameJustin M. Keyes2026-05-30
|
* vim-patch:9.2.0562: filetype: SGF files are not recognizedzeertzjq2026-05-30
| | | | | | | | | | | | | | | Problem: filetype: SGF files are not recognized Solution: Detect *.sgf as sgf filetype (Borys Lykah) Reference: https://www.red-bean.com/sgf/index.html closes: vim/vim#20349 https://github.com/vim/vim/commit/dda45ba88fef901ac524c158eaeb1ce799dde273 Co-authored-by: Borys Lykah <lykahb@fastmail.com>
* vim-patch:9.2.0560: filetype: busybox shebang lines are not recognizedzeertzjq2026-05-30
| | | | | | | | | | | | Problem: filetype: busybox shebang lines are not recognized Solution: Add filetype detection pattern for #!busybox sh, detect ash as shell in the shebang lines (Christoffer Aasted). closes: vim/vim#20358 https://github.com/vim/vim/commit/69f402e97f9f8e5dbf17549c4813cf932c91a4ee Co-authored-by: Christoffer Aasted <dezzadk@gmail.com>
* vim-patch:9.2.0559: filetype: Kaitai struct files are not recogonizedzeertzjq2026-05-30
| | | | | | | | | | | | | | Problem: filetype: Kaitai struct files are not recogonized Solution: Detect *.ksy files as yaml filetype (Wu, Zhenyu) Reference: https://doc.kaitai.io/ closes: vim/vim#20353 https://github.com/vim/vim/commit/73e619d699574f1fc96ce2f04c1e243748c4d7dc Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
* vim-patch:9.2.0558: filetype: Popcap Reanimation files are not recognizedzeertzjq2026-05-30
| | | | | | | | | | | | | | Problem: filetype: Popcap Reanimation files are not recognized Solution: Recognize *.reanim files as xml filetype (Wu, Zhenyu). Reference: https://github.com/wszqkzqk/PvZ-Portable closes: vim/vim#20354 https://github.com/vim/vim/commit/c83d2f888e6a0a399f4c1c30bec1fd9e5b9664b1 Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
* vim-patch:9.2.0557: filetype: Kawasaki Robots files are not recognizedzeertzjq2026-05-30
| | | | | | | | | | | | | | | | | | Problem: filetype: Kawasaki Robots files are not recognized Solution: Detect *.pg as kawasaki_as filetype, add filetype detection for *.as as atlas or kawasaki_as filetype (KnoP-01). In Kawasaki robots (https://kawasakirobotics.com/products-robots/) AS language *.pg is the extention for a program file and *.as is for a complete backup. closes: vim/vim#20370 https://github.com/vim/vim/commit/dec3d6c7da637de5717c27d24a2f7ca50f7180a3 Co-authored-by: KnoP-01 <knosowski@graeffrobotics.de>
* feat(lua): support table `lhs` in vim.keymap.set()/del() #39948Olivia Kinnear2026-05-29
| | | | | | | | | | | | | | | | | Problem: It is repetitive to map multiple keymaps to do the same thing. Here are some cases where being able to do this would be useful: -- Visual movement for both j/k and down/up: vim.keymap.set({ 'n', 'x' }, { 'j', '<Down>' }, 'v:count == 0 ? "gj" : "j"', { expr = true }) vim.keymap.set({ 'n', 'x' }, { 'k', '<Up>' }, 'v:count == 0 ? "gk" : "k"', { expr = true }) -- Map multiple keys to `<Nop>` concisely: vim.keymap.set({ 'n', 'x' }, { '<Leader>', '<Localleader>', '<CR>' }, '<Nop>') -- Remove multiple keymaps at once: vim.keymap.del('n', { 'gri', 'grn', 'grr' }) Solution: Support the `lhs` of `vim.keymap.set()` and `vim.keymap.del()` being a table, in the same way that `modes` can be.
* fix(vim.fs): fs.dir() may return nil "type" on some filesystems #39749abdulahmoda2026-05-29
| | | | | | | | | | | | | | Problem: Currently, only some filesystems (Btrfs, ext2, ext3, ext4) have full support of accessing the `dirent` entry-type. On other filesystems, `uv.fs_scandir_next` may return `nil` for an existing but unsupported entry-type. This means consumers (such as `fs.dir()`), cannot know if `nil` means "non-existent" or "unsupported". Solution: Fall back to `uv.fs_lstat` when `etype` is `nil`; return "unknown" if it fails.
* docs(treesitter): describe pattern_id of capturesatusy2026-05-29
|
* vim-patch:9.2.0551: filetype: Tolk files are not recognizedzeertzjq2026-05-29
| | | | | | | | | | | | | | | | | | Problem: filetype: Tolk files are not recognized Solution: Detect *.tolk files as tolk filetype, include a syntax and filetype plugin (redavy) Tolk is a new-generation language for writing smart contracts on TON blockchain, which is vim/vim#1 in speed among other chains. Reference: https://docs.ton.org/blockchain-basics/tolk/overview closes: vim/vim#20320 https://github.com/vim/vim/commit/b9bba99712907c6c2f7139aa3bd3739a100d6a58 Co-authored-by: redavy <hello.redavy@proton.me>
* refactor: rename `vim.transport` to `vim.net.transport` #40021Yi Ming2026-05-28
|
* docs(lsp): document on_list deduplication #39941Puneet Dixit2026-05-27
| | | | | | | | | | Problem: Deduplicating LSP locations in the default handler changes list behavior for every user, while some configurations may intentionally return matching locations from multiple clients. Solution: Document how users can deduplicate locations in an on_list handler with vim.list.unique(). Co-authored-by: Deepak kudi <deepakkudi23@adsl-172-10-9-116.dsl.sndg02.sbcglobal.net> Co-authored-by: Puneet Dixit <236133619+puneetdixit200@users.noreply.github.com>
* fix(lsp): unwanted redraw for buffer not in window #40002luukvbaal2026-05-27
| | | | | Problem: Redrawing when a loaded buffer is not shown in any window on the current tabpage. Solution: Check that buffer is shown in a (normal) window before redrawing.
* vim-patch:9.2.0539: filetype: too many Bitbake include files are recognized ↵zeertzjq2026-05-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | (#40014) Problem: filetype: too many Bitbake include files are recognized (Brahmajit Das, after v9.1.1732) Solution: Tighten the pattern to detect BitBake include files, update tests (Martin Schwan). Be more strict when detecting BitBake inc files. In particular, only match include keywords and variable assignments at the beginning of a line (excluding whitespace). Use non-capturing groups to slightly improve performance. Use regex or-operators to exactly match BitBake assignment operators. The previous expression would falsely match FOO .=. "bar" , which is not valid BitBake syntax. The new capturing group is more specific and matches only valid assignments. fixes: vim/vim#20288 closes: vim/vim#20335 https://github.com/vim/vim/commit/2df68c8e4bc03a5222218e22e74897861b8c1896 Co-authored-by: Martin Schwan <m.schwan@phytec.de>
* vim-patch:9.2.0538: Cannot keep leading whitespace in %{} statusline expr ↵zeertzjq2026-05-26
| | | | | | | | | | | | | | | (#40007) Problem: A leading space in the result of a %{} item is sometimes stripped, and an all-digit result is converted to a number. Solution: Add %0{} atom which inserts the expression result verbatim (glepnir) fixes: vim/vim#3898 closes: vim/vim#20315 https://github.com/vim/vim/commit/e8d7a40b98ce4062834399f097216213a0088ff3 Co-authored-by: glepnir <glephunter@gmail.com>
* fix(lsp): calc correct screen_width when opts.relative == 'editor' (#39977)acehinnnqru2026-05-24
|
* vim-patch:c7645fc: runtime(doc): add a few references to mouse behaviour ↵zeertzjq2026-05-23
| | | | | | | | | (#39959) fixes: vim/vim#20281 https://github.com/vim/vim/commit/c7645fcda50f95cc098545b70ce937a986b997d1 Co-authored-by: Christian Brabandt <cb@256bit.org>
* refactor(lsp): avoid using coroutine when parsing framesYi Ming2026-05-22
|
* refactor(lsp): message stream abstraction for message framingYi Ming2026-05-22
|
* refactor(lsp): move `vim.lsp._transport` to `vim.net._transport`Yi Ming2026-05-22
|
* Merge #39939 from marcuscaisey/lsp-completion-detailsJustin M. Keyes2026-05-22
|\
| * refactor(lsp): centralise complete item info generation logicMarcus Caisey2026-05-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: The logic for generating the complete item `info` is spread across `_lsp_to_complete_items`, the `CompleteChanged` event handler, and `CompletionResolver:request`. This has previously caused the `info` shown for resolved (via `completionItem/resolve`) and unresolved items to differ. Solution: Centralise the logic in a new `complete_item_info` function which is now solely responsible for determining: 1. The `info` to show. 2. The markup kind of the `info`. 3. Whether the `info` is complete. This simplifies the interaction between the 3 functions mentioned in the problem: - `_lsp_to_complete_items` calls `complete_item_info` and passes along the markup kind and whether the item needs resolving via the complete item's `user_data`. - The `CompleteChanged` consumes the markup kind and whether the item needs resolving from the complete item's `user_data`. - `CompletionResolver:request`, like `_lsp_to_complete_items` calls `complete_item_info` again and updates the current `info` if it's changed.
| * fix(lsp): show detail in popup when server can't completionItem/resolveMarcus Caisey2026-05-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: `CompletionItem.detail` is only shown in the info popup if the server supports `completionItem/resolve`. Solution: If the server doesn't support `completionItem/resolve`, prepend the complete item `info` with `CompletionItem.detail` in a fenced codeblock, same as we do when the server supports `completionItem/resolve`. To ensure that completion items are displayed in the same way, regardless of whether the server supports `completionItem/resolve`, i've extracted out the test logic from the `selecting an item triggers completionItem/resolve + (snippet) preview` case so that we can run the same tests against a server which supports `completionItem/resolve` and one which doesn't. Hopefully this should prevent the two behaviours diverging again.
| * fix(lsp): resolve CompletionItem if resolvable fields aren't populatedMarcus Caisey2026-05-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: If `CompletionItem.documentation` is populated but `detail` is not, then `detail` is not resolved. Solution: Ensure that we resolve a `CompletionItem` if either `detail` or `documentation` are not populated. I've also removed `detail` from the popup menu since otherwise it will be populated in both the popup menu and the info popup after the `CompletionItem` has been resolved. I think the info popup is the best place for it anyway as when there is a completion item with a long popup menu entry (when `detail` is a medium/long function signature for instance), the whole popup menu gets widened and this steals horizontal space that could be used to display the `documentation`. Now with `detail` and `documentation` in the info popup, they share the same horizontal space. This also aligns with how VSCode, nvim-cmp, blink.cmp, and mini.nvim display `detail`.
| * fix(lsp): generate snippet preview from resolved textEdit.newTextMarcus Caisey2026-05-21
| | | | | | | | | | | | | | | | | | Problem: When a resolved `CompletionItem` with kind `Snippet` populates `textEdit` instead of `insertText`, the contents are not previewed. Solution: Generate the snippet preview from `textEdit.newText` as well.
* | fix(lsp): validate that `workspace_edit` isn't `nil` (#39947)Maria Solano2026-05-21
| |
* | fix(lsp): advertise that CompletionItem.detail can be resolved (#39934)Marcus Caisey2026-05-21
|/ | | | | | | | | Problem: We can resolve the `CompletionItem.detail` field but don't advertise this capability. Solution: Add `detail` to `textDocument.completion.completionItem.resolveSupport.properties`.
* fix(ui2): unable to stop display of very long message #39823luukvbaal2026-05-21
| | | | | | | | | | | | Problem: Processing of a very long message may take a long time; there is no visual feedback of work being done, and no way to abort processing. Calculating text height for spill indicator inhibits performance for very long message. Solution: Whenever writing part of a message is taking longer than 100ms, show the first part of the message, while checking for CTRL-C. Calculate ('wrap'-ed) text height accurately until 'lines', use line count beyond that.
* refactor(docs): generate tui.txt $NVIM_TERMDEFS keys #39836Kyle2026-05-21
| | | | | | | | | Problem: Potential documentation drift in `tui.txt` if fields for `$NVIM_TERMDEFS` change. Solution: Generate docs for `tui.txt`. Add `brief_xform` to `gen_vimdoc.lua` to allow transforming briefs during generation.
* fix(lsp): flush change notifications on save (#39894)Maria Solano2026-05-20
|
* refactor: introduce nvim_on internally #39883Justin M. Keyes2026-05-20
| | | | | | | | | Problem: `nvim_create_autocmd` is too verbose and its `callback` requires extra "nesting". Solution: Introduce `nvim_on`. Start using it internally. Then we can get a feel for how it should look before making it public.
* fix(vim.secure): read() command injection vulnerability #39918Justin M. Keyes2026-05-20
| | | | | | | | | Problem: Malicious filename can execute code because of ":" cmdline expansion. Solution: Use `fnameescape()`. fix https://github.com/neovim/neovim/issues/39914
generated by cgit (git 2.34.1) at 2026-10-20 18:41:06 +0000