aboutsummaryrefslogtreecommitdiff
path: root/runtime/lua/vim
Commit message (Collapse)AuthorAge
...
* docs: drop vim.pack WIP note, add example code #37229Evgeni Chasnovski2026-01-07
|
* feat(editor): :source can run Lua codeblock / ts injection #36799benarcher26912026-01-07
| | | | | | | | | Problem: Can't use `:source` to run a Lua codeblock (treesitter injection) in a help (vimdoc) file. Solution: Use treesitter to parse the range and treat it as Lua if detected as such.
* fix(filetype): fix typo (#37286)zeertzjq2026-01-07
| | | | | Follow-up to #37278. Not sure how I missed the typo. I even remember checking the PR twice...
* docs: misc (#37280)zeertzjq2026-01-07
| | | | | | | | | | | | | | | | | | | | Close #36806 Close #36812 Close #37003 Close #37016 Close #37038 Close #37039 Close #37157 Close #37185 Close #37213 Co-authored-by: saroj_r <sarojregmi.official@gmail.com> Co-authored-by: Olivia Kinnear <git@superatomic.dev> Co-authored-by: Igor <igorlfs@ufmg.br> Co-authored-by: Justin Roberts <JustinEdwardLeo@gmail.com> Co-authored-by: "Mike J. McGuirk" <mike.j.mcguirk@gmail.com> Co-authored-by: Aymen Hafeez <49293546+aymenhafeez@users.noreply.github.com> Co-authored-by: Peter Cardenas <16930781+PeterCardenas@users.noreply.github.com> Co-authored-by: DrNayak2306 <dhruvgnk.work@gmail.com>
* vim-patch:9.1.2062: filetype: djot files are not recognizedzeertzjq2026-01-07
| | | | | | | | | | | | | | | Problem: filetype: djot files are not recognized Solution: Detect *.dj and *.djot files as djot filetype (Hoang Nguyen). Reference: - https://djot.net/ closes: vim/vim#19105 https://github.com/vim/vim/commit/8d0fcff002d1198f0a6cfe211f6bdcd91466e70f Co-authored-by: Hoang Nguyen <folliekazetani@protonmail.com>
* vim-patch:9.1.2061: filetype: Koka files are not recognizedzeertzjq2026-01-07
| | | | | | | | | | | | | | Problem: filetype: Koka files are not recognized Solution: Detect *.kk files as koka filetype (Hoang Nguyen). Reference: - https://koka-lang.github.io/koka/doc/index.html closes: vim/vim#19104 https://github.com/vim/vim/commit/969a4a0ba5dc53a8745e9ece10df13f98572603b Co-authored-by: Hoang Nguyen <folliekazetani@protonmail.com>
* vim-patch:9.1.2060: filetype: Rasi include files are not recognizedzeertzjq2026-01-07
| | | | | | | | | | | | | | Problem: filetype: Rasi include files are not recognized Solution: Detect *.rasinc as rasi filetype (Hoang Nguyen) Reference: - https://github.com/davatorium/rofi/blob/next/doc/rofi-theme.5.markdown#file-extension closes: vim/vim#19103 https://github.com/vim/vim/commit/b084b8f1db40cba2971db3bdb4528770556e7ddc Co-authored-by: Hoang Nguyen <folliekazetani@protonmail.com>
* vim-patch:9.1.2059: filetype: Nickel files are not recognizedzeertzjq2026-01-07
| | | | | | | | | | | | | | | | Problem: filetype: Nickel files are not recognized Solution: Detect *.ncl files as nickel filetype (Hoang Nguyen) Reference: - https://nickel-lang.org/getting-started/ - https://github.com/tweag/nickel/tree/master/examples closes: vim/vim#19102 https://github.com/vim/vim/commit/88f3ac34ea465dc6e74835e0c367220815f76a32 Co-authored-by: Hoang Nguyen <folliekazetani@protonmail.com>
* fix(diagnostic): display 1-based related information line/col numbers (#37093)Robert Muir2026-01-04
| | | | | | | | | Problem LSP Related Information line and column numbers are 0-based. Displaying them this way can confuse the user, since vim line/col numbers are typically displayed 1-based. Solution Display the line and column numbers as 1-based.
* vim-patch:93eb081: runtime(doc): Clarify visual mark behavior in getpos(), ↵zeertzjq2026-01-03
| | | | | | | | | | | | | | setpos() (#37223) Add documentation notes explaining that visual marks '< and '> have different behaviors in getpos() and setpos(). Also fix a small typo. closes: vim/vim#19070 https://github.com/vim/vim/commit/93eb081eee92180a495d72a495542b24a873e2f3 Co-authored-by: Larson, Eric <numeric.larson@gmail.com>
* vim-patch:9.1.2042: filetype: systemd quadlet files are not recognized (#37208)zeertzjq2026-01-03
| | | | | | | | | | | | | | | | | Problem: filetype: systemd quadlet files are not recognized Solution: Detect additional patterns as systemd filetype (Ac5000) Reference: - https://docs.podman.io/en/latest/markdown/podman.1.html - https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html - https://docs.podman.io/en/latest/markdown/podman-quadlet.1.html fixes: vim/vim#15078 closes: vim/vim#19057 https://github.com/vim/vim/commit/0f93c988e97325bfc54654bc2cf4178fb11ba865 Co-authored-by: Ac5000 <15003210+Ac5000@users.noreply.github.com>
* vim-patch:9.1.2043: filetype: kos files are not reconizedChristian Clason2026-01-02
| | | | | | | | | | | | | | | Problem: filetype: kos files are not reconized Solution: Detect *.kos files as kos filetype (Chris Dragan) Reference: - https://github.com/kos-lang/kos closes: vim/vim#19056 https://github.com/vim/vim/commit/96a1caac6b39b523a32d0554cb95e92dbb81e17f Co-authored-by: Chris Dragan <chris@dragan.dev>
* fix(lsp): `:lsp restart` restarts on client exit #37125Olivia Kinnear2026-01-02
| | | | | | | | | | | | | | Problem: `:lsp restart` detects when a client has exited by using the `LspDetach` autocommand. This works correctly in common cases, but breaks when restarting a client which is not attached to any buffer. It also breaks if a client is detached in between `:lsp restart` and the actual stopping of the client. Solution: Move restart logic into `vim/lsp/client.lua`, so it can hook in to `_on_exit()`. The public `on_exit` callback cannot be used for this, as `:lsp restart` needs to ensure the restart only happens once, even if the command is run multiple times on the same client.
* fix(diagnostic): check for extmark in get_logical_pos #37127Kira Kawai2026-01-02
| | | | | Problem: The function get_logical_pos did not account for the possibility that a diagnostic might not have an associated extmark, leading to potential errors or incorrect behavior. Solution: Add a check for diagnostic._extmark_id and return the logical positions directly if it does not exist.
* fix(lsp): improve dynamic registration handling #37161Tristan Knight2026-01-02
| | | | | | | | Work on #37166 - Dynamic Registration Tracking via Provider - Supports_Method - Multiple Registrations - RegistrationOptions may dictate support for a method
* vim-patch:9.1.2035: filetype: filetype: Fennel fnlm files are not recognized ↵zeertzjq2025-12-31
| | | | | | | | | | | | | | (#37178) Problem: filetype: Fennel fnlm files are not recognized (Alexei Mozaidze, after v9.1.2034) Solution: Detect *.fnlm files as fennel filetype, revert detecting *.fnml files related: vim/vim#19047 https://github.com/vim/vim/commit/ea189a6f4d2a1f4a1f2822cbd2aed0a584ecceea Co-authored-by: Christian Brabandt <cb@256bit.org>
* vim-patch:9.1.2034: filetype: Fennel fnml files are not recognized (#37176)zeertzjq2025-12-31
| | | | | | | | | | | | | | Problem: filetype: Fennel fnml files are not recognized (Alexei Mozaidze) Solution: Detect *.fnml files as fennel filetype Reference: - https://fennel-lang.org/changelog#160--2025-10-13 fixes: vim/vim#19047 https://github.com/vim/vim/commit/9c87af5c3cf5dc483c64d54f2677c4906d0545fa Co-authored-by: Christian Brabandt <cb@256bit.org>
* fix(treesitter): use metadata in :EditQuery captures #37116Peter Cardenas2025-12-30
| | | | | | | Problem: When the `#offset!` directive is used with `:EditQuery`, the query does not take the offset into consideration when creating the extmark to preview the capture. Solution: Use the capture metadata to modify the node range before creating the extmark.
* Merge #37113 from echasnovski/pack-better-revertJustin M. Keyes2025-12-30
|\
| * feat(pack): allow running `update()` without Internet connectionEvgeni Chasnovski2025-12-26
| | | | | | | | | | | | | | | | | | | | Problem: There is now way to run `update()` without Internet connection while there are some workflows that do not require it. Like "switch plugin version" and "revert latest update". Solution: Add `opts.offline` to `update()`. This also allows now to treat `vim.pack.update(nil, { offline = true })` as a way to interactively explore currently installed plugins.
| * feat(pack): allow choosing update target in `update()`Evgeni Chasnovski2025-12-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: There are two fairly common workflows that involve lockfile and can be made more straightforward in `vim.pack`: 1. Revert latest update. Like if it introduced unwanted behavior. 2. Update to a revision in the lockfile. Like if already updated on another machine, verified that everything works, `git add` + `git commit` + `git push` the config, and want to have the same plugin states on current machine. Solution: Make `update` allow `opts.target`. By default it uses `version` from a plugin specification (like a regular "get new changes from source" workflow). But it also allows `"lockfile"` value to indicate that target revision after update should be taken from the current lockfile verbatim. With this, the workflows are: 1. Revert (somehow) to the lockfile before the update, restart, and `vim.pack.update({ 'plugin' }, { target = 'lockfile' })`. If Git tracked, revert with `git checkout HEAD -- nvim-pack-lock.json`. For non-VCS tracked lockfile, the revisions can be taken from the log file. It would be nicer if `update()` would backup a lockfile before doing an update, but that might require discussions. 2. `git pull` + `:restart` + `vim.pack.update(nil, { target = 'lockfile' })`. The only caveats are for new and deleted plugins: - New plugins (not present locally but present in the lockfile) will be installed at lockfile revision during restart. - Deleted plugins (present locally but not present in the lockfile) will still be present: both locally *and* in the lockfile. They can be located by `git diff -- nvim-pack-lock.json` and require manual `vim.pack.del({ 'old-plugin1', 'old-plugin2' })`.
* | fix(diagnostic): unstable sorting by severity #37154glepnir2025-12-30
| | | | | | | | | | Problem: random order for same-severity diagnostics, severity_sort reversed. Solution: add stable comparison with _extmark_id tiebreaker.
* | Merge #37142 from echasnovski/pack-safer-delJustin M. Keyes2025-12-30
|\ \
| * | feat(pack)!: suggest "delete" code action only for not active pluginsEvgeni Chasnovski2025-12-28
| | | | | | | | | | | | | | | | | | | | | | | | Problem: Deleting active plugins can lead to a situation when it is reinstalled after restart. Solution: Suggest "delete" code action only for not active plugins. Whether a plugin is not active is visible by a hint in its header.
| * | feat(pack): hint in confirmation buffer that plugin is not activeEvgeni Chasnovski2025-12-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: After `vim.pack.update()` it is not clear if plugin is active or not. This can be useful to detect cases when plugin was removed from 'init.lua' but there was no `vim.pack.del()`. Solution: Add ` (not active)` suffix with distinctive highlighting to header of plugins that are not active. It will also be shown in in-process LSP document symbols to have quick reference about which plugins are not active.
| * | feat(pack)!: make `del()` only remove non-active plugins by defaultEvgeni Chasnovski2025-12-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Using `vim.pack.del()` to delete active plugin can lead to a situation when this plugin is reinstalled after restart. Removing plugin from 'init.lua' is documented, but can be missed. Solution: Make `del()` only remove non-active plugins by default and throw an informative error if there is an active plugin. Add a way to force delete any plugin by adding `opts.force`. This also makes `del()` signature be the same as other functions, which is nice.
* | | Merge #36870 from justinmk/luacoreJustin M. Keyes2025-12-30
|\ \ \
| * | | build: move shared.lua to _core/Justin M. Keyes2025-12-30
| | | |
| * | | build: ship "_core/*" as bytecode (built-into Nvim binary)Justin M. Keyes2025-12-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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(vim.fs): avoid fn.fnamemodify in fs.root #37162Jason Shipman2025-12-30
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: vim.fs.root uses vim.fn.fnamemodify. vim.fn table isn't available from nvim -ll or thread contexts. Solution: Swap out vim.fn.fnamemodify for vim.fs.abspath. This is a temporary workaround and may be reverted since the long-term plan is to use more fast=true "fn" functions from vim.fs where possible.
* / / feat(terminal): include sequence terminator in TermRequest event (#37152)Kyle2025-12-29
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Terminals should respond with the terminator (either BEL or ST) used in the query so that clients can reliably parse the responses. The `TermRequest` autocmd used to handle background color requests in the terminal does not have access to the original sequence terminator, so it always uses BEL. #37018 Solution: Update vterm parsing to include the terminator type, then forward this data into the emitted `TermRequest` events for OSC/DCS/APC sequences. Update the foreground/background `TermRequest` callback to use the same terminator as the original request. Details: I didn't add the terminator to the `TermResponse` event. However, I assume the `TermResponse` event doesn't care about the terminator because the sequence is already parsed. I also didn't update any of the functions in `src/nvim/vterm/state.c` that write out responses. It looked like those all pretty much used ST, and it would be a much larger set of changes. In that same file, there's also logic for 8 bit ST sequences, but from what I can tell, 8 bit doesn't really work (see `:h xterm-8bit`), so I didn't use the 8 bit ST at all.
* | vim-patch:9.1.2027: filetype: bicep filetype used for 2 bicep file types ↵zeertzjq2025-12-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (#37130) Problem: filetype: bicep filetype used for 2 bicep file types Solution: Detect *.bicepparam files as bicep-param filetype, include new bicep-params and bicep filetype plugin (Scott McKendry) The bicep language server handles parameter files differently than regular bicep files. Treating them the same at the editor level leads to false positive diagnostics in the editor. References: Bicep Language Constants: - https://github.com/Azure/bicep/blob/51392d32ca2c8b94b1bb7a255e78e1d559d12573/src/Bicep.Core/LanguageConstants.cs#L23 VS Code Extension definition: - https://github.com/Azure/bicep/blob/51392d32ca2c8b94b1bb7a255e78e1d559d12573/src/vscode-bicep/package.json#L47 closes: vim/vim#19026 https://github.com/vim/vim/commit/4e722fdfdd987c11136e3533bd65d0ed4d15f829 Co-authored-by: Scott McKendry <me@scottmckendry.tech>
* | vim-patch:9.1.2024: 'fsync' option cannot be set per buffer (#37129)zeertzjq2025-12-28
| | | | | | | | | | | | | | | | | | | | | | Problem: 'fsync' option cannot be set per buffer Solution: Make 'fsync' option global-local (glepnir) closes: vim/vim#19019 https://github.com/vim/vim/commit/4d5b30372663e8ea356b25fe94334558c6ae283f Co-authored-by: glepnir <glephunter@gmail.com>
* | vim-patch:9.1.2021: filetype: fluent files are not recognized (#37117)zeertzjq2025-12-27
|/ | | | | | | | | | | | | Problem: filetype: fluent files are not recognized Solution: Detect *.ftl files as fluent filetype (ners) References: - https://projectfluent.org/ closes: vim/vim#19011 https://github.com/vim/vim/commit/b91b30643af00947e4b0f8758b3e44bb9927faee Co-authored-by: ners <ners@gmx.ch>
* feat(lsp): on_accept can return item to customize behavior #37092Yi Ming2025-12-26
| | | | | | | | Problem: `on_accept` is a bit cumbersome to customize. Solution: * Before: users had to override the entire `on_accept` logic for their changes to be applied. * Now: users can modify the item and return it to apply the modified changes, or return `nil` to fully customize how the changes are applied.
* docs(pack): use more tags and add "Use shorter source" exampleEvgeni Chasnovski2025-12-25
|
* feat(pack)!: change `src` of installed plugin inside `update()` in placeEvgeni Chasnovski2025-12-25
| | | | | | | | | | | | | | | | | | | Problem: Changing `src` of already installed plugin currently takes effect immediately inside `vim.pack.add()` and acts as "delete and later fresh install". Although more robust, this might lead to unintentional data loss (since plugin is deleted) if the plugin was manually modified or the new source is not valid. Also this introduces unnecessary differentiation between "change `version`" and "change `src`" of already installed plugin. Solution: Require an explicit `vim.pack.update()` to change plugin's source. It is done by conditionally changing `origin` remote of the Git repo. The effect does not require update confirmation in order to have new changes fetched from the new `src` right away. If in the future there are more types of plugins supported (i.e. not only Git repos), also do extra work (like delete + install) during `vim.pack.update()`.
* fix(ex): error handling for `:lsp` #37061Olivia Kinnear2025-12-25
|
* vim-patch:2006415: runtime(doc): add reference to searchcount() functionzeertzjq2025-12-24
| | | | | | https://github.com/vim/vim/commit/20064150169a94380abef37d3966c864531d1d92 Co-authored-by: Christian Brabandt <cb@256bit.org>
* fix(lua): separate vim.{g,b,w,t} types #37081phanium2025-12-23
| | | | | | | | Problem: When `vim.g.foo = 1`, `vim.b.foo` also appears as a completion candidate (when use emmylua_ls). Solution: Define separate types.
* vim-patch:9.1.2008: filetype: hylo files are not recognizedzeertzjq2025-12-23
| | | | | | | | | | | | | | Problem: filetype: hylo files are not recognized Solution: Detect *.hylo files as hylo filetype (Ambrus Tóth) References: - https://hylo-lang.org/ closes: vim/vim#18994 https://github.com/vim/vim/commit/9c9982240afca5c5efe6f235f2157a5e5165170c Co-authored-by: Ambrus Tóth <ping@ambrus.dev>
* vim-patch:9.1.2007: filetype: bpftrace hashbang lines are not recognizedzeertzjq2025-12-23
| | | | | | | | | | | Problem: bpftrace files are not recognized from the hashbang line. Solution: Add a hashbang check (Stanislaw Gruszka) closes: vim/vim#18992 https://github.com/vim/vim/commit/f2814754c0cd39875adcadffcb73206a83a46099 Co-authored-by: Stanislaw Gruszka <stf_xl@wp.pl>
* fix(treesitter.foldexpr): duplicate callbacks #37048Jaehwang Jung2025-12-21
| | | | | | | | | Problem: VimEnter clears foldinfo, so register_cbs is called again after VimEnter. The duplicate parser callbacks break incremental fold computation. Solution: Check if the callbacks are already registered.
* Merge #37057 docsJustin M. Keyes2025-12-21
|\
| * fix(options): deprecate 'gdefault', 'magic'Justin M. Keyes2025-12-20
| |
* | fix(statusline): diagnostics spacing #36897Olivia Kinnear2025-12-20
|/
* docs(lua): iInconsistent vim.keymap param name #37026Bryan Turns2025-12-20
| | | | | | |