Problem: If the lockfile points to the revision that is not on disk, the
`:checkhealth vim.pack` suggests to run `vim.pack.update()`. Although
usually it should resolve the problem, it is not always the case: like
if the state on disk is already the latest available.
Solution: Add an extra suggestion with a more drastic measure by
manually removing `rev` field from the lockfile for it to be repaired
after the `:restart`.
Problem: runtime(tar): but with dotted path
Solution: Do not strip everything after the first dot
(Aaron Burrow)
tar#Extract was getting the extensionless basename by
stripping away everything starting with the leftmost
dot. So if a directory had a dot or the file had an
'extra' dot then the code did the wrong thing. For
example, if it was given:
/tmp/foo.bar/baz.tar.gz
Then it would treat /tmp/foo as the extensionless
basename, but it actually should have grabbed:
/tmp/foo.bar/baz
This patch fixes the issue by instead looking at the
rightmost dot(s).
This bug was discovered by ChatGPT 5.4. I wrote the
patch and tested vim.
closes: vim/vim#199304a1bcc67b4
Co-authored-by: Aaron Burrow <burrows@fastmail.com>
Problem: patch 9.2.0325: runtime(tar): bug in zstd handling
Solution: use correct --zstd argument, separated from other arguments,
rework testing framework (Aaron Burrow).
The tar.vim plugin allows vim to read and manipulate zstd archives,
but it had a bug that caused extraction attempts to fail.
Specifically, if the archive has a .tar.zst or .tzst extension, then
the code was generating invalid extraction commands that looked like
this:
tar --zstdpxf foo.tar.zst foo
When they should be like this:
tar --zstd -pxf foo.tar.zst foo
This patch changes the flag manipulation logic so that --zstd isn't
glued to pxf.
The labor for this change was divided between ChatGPT 5.4 and me.
ChatGPT 5.4 identified the issue (from a code scan?), and I wrote
the patch and tested vim.
related: vim/vim#1993000285c035a
Note: tests need the next patch to pass in Nvim.
Co-authored-by: Aaron Burrow <burrows@fastmail.com>
The regex for status line highlighting was too broad, `jjComment` lines
containing e.g. the letter 'A' followed by a space anywhere in the line
were highlighted.
related: vim/vim#19879959817472d
Co-authored-by: Joël Stemmer <jstemmer@google.com>
Problem:
`vim.lsp.buf.definition`/`vim.lsp.buf.declaration` use the same underlying code
via `get_locations`, whereas `vim.lsp.buf.reference` does not. This is because
`buf.reference` does not perform a jump when there is only one item.
Solution:
In #38510, I simplified the jump logic using `:cfirst`, so they can now share
code more easily. Additionally, this PR enables `buf.definition` to display the
corresponding qflist name.
Problem:
`:help dev-name-common` states that "buf" should be used instead of
"buffer" but there are cases where buffer is mentioned in the lua API.
Solution:
- Rename occurrences of "buffer" to "buf" for consistency with the
documentation.
- Support (but deprecate) "buffer" for backwards compatibility.
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Problem:
Since 2f6d1d3c88, `apply_text_edits`
unconditionally sets `buflisted=true`, causing spurious BufDelete events
if plugins restore the original 'buflisted' state on unlisted buffers:
65ef6cec1c/src/nvim/option.c (L2159-L2169)
Solution:
- Don't set 'buflisted' in `apply_text_edits`. Set it more narrowly, in
`apply_workspace_edit` where the semantics requires affected buffers
to be visible to the user.
- Also skip setting 'buflisted' if it would not be changed, to avoid
redundant `OptionSet` events.
Problem: nvim_clear_autocmds() does not type check "event" correctly, and also
treats an empty array "event" like nil.
Solution: fix type checking. Treat empty array "event" as a no-op, like
nvim_exec_autocmds(). Add some extra tests.
Likewise the nil handling change may be considered breaking if anyone
(unintentionally) relied on that. It was also true that integer, function, etc.
"event"s would also be treated like nil!
Note that an empty string "event" is still an error, as that's must be an exact
match on an event name.
Problem: nvim_exec_autocmds() documentation incorrectly describes the default
for "pattern" as *, when it's actually the current file name (like :doautocmd).
Solution: correct it. Add a test.
Problem: in autocmd APIs, a non-nil "pattern" containing only empty
'sub'-patterns is silently treated as nil, causing the fallback value to be
unexpectedly used instead.
Solution: for nvim_create_autocmd(), raise a validation error (as no autocmds
would be created). For nvim_{exec,clear}_autocmds(), make it a no-op (as
matching no autocmds is not an error).
Problem:
The current LSP diagnostic implementation can't differ between a pull
diagnostic with no identifier and a set of diagnostics provided via push
diagnostics.
"Anonymous pull providers" are expected by the protocol https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#diagnosticOptions
, depending on how the capability was registered:
- Dynamic registrations have an identifier.
- Static registrations will not.
Solution:
Restore the `is_pull` argument removed in
https://github.com/neovim/neovim/pull/37938, keeping the identifier of
pull diagnostic collections.
Problem: vim.VersionRange had no __eq metamethod, so comparing 2 distinct
but same value instances always returned false. In vim.pack.add this caused
redundant lockfile rewrites, even when the resulting lockfile content was
unchanged.
Solution: Add __eq metamethod on vim.VersionRange
Problem:
`:checkhealth vim.lsp` validates configured filetypes against
`getcompletion('', 'filetype')`. This only reflects runtime support
files.
This causes false warnings in `:checkhealth vim.lsp` for configured
filetypes that are known to the Lua filetype registry, including
values added with `vim.filetype.add()` and built-in registry-only
filetypes.
Solution:
Build the healthcheck's known-filetype set from both
`getcompletion('', 'filetype')` and `vim.filetype.inspect()`.
Problem:
`vim.Range` and `vim.Pos` have signature mismatches on the docs of some functions.
Solution:
Split the "module" functions from the "class" functions (just like it's done in other modules like `vim.version`) and regenerate the docs.
Problem: When Neovim is built with Zig, `:checkhealth` falsely reports
"Non-optimized debug build" for release builds. The extraction regex
stops at the first space, and the validation regex only lists CMake
build type names.
Solution: Fix the extraction regex to capture the full build type string
and add Zig optimization levels (ReleaseFast, ReleaseSafe, ReleaseSmall)
to the validation regex.
AI-assisted: Claude Code
Problem: No way of inspecting the (user-added) filetype detection rules.
Solution: Add `vim.filetype.inspect()` returning copies of the internal
`extension`, `filename`, `pattern` tables. Due to the dynamic nature of
filetype detection, this will in general not allow getting the list of
known filetypes, but at least one can see if a given extension is known.
Problem:
We normally get the background color via continuous reporting. However,
if we were backgrounded while the light/dark mode changed, we won't have
received the report, and we'll have the wrong background color.
Without this change, if you background nvim, toggle the light/dark mode,
resume, and check `:set bg`, it will not match the current state.
Solution:
Query it on resume as well. (This requires separating the query from the
flush, to just do the query along with all the others, while waiting to
flush until we've set up uv.)
With this change, if you background nvim, toggle the light/dark mode,
resume, and check `:set bg`, it will have updated.
Problem: `buf` is optional even though its needed to perform conversions
and the ordering of `(buf, row, col)` is not consistent.
Solution: make `buf` mandatory on `vim.range` and `vim.pos` and enforce
the `buf, row, col` ordering
Problem: runtime(tar): some issues with lz4 support
Solution: Fix bugs (see below) (Aaron Burrow)
The tar plugin allows users to extract files from tar archives that are
compressed with lz4. But, tar#Extract() builds malformed extraction commands
for lz4-compressed tar archives. This commit fixes three issues in that code.
The first affects archives with a .tlz4 extension and the other two affect
archives with .tar.lz4 extension (but one of these is symmetric to the issue
that .tlz4 archives had).
(1) When trying to extract .tlz4 archives the command created by
tar#Extract looked like this:
tar -I lz4pxf foo.tlz4 foo
This isn't right. It should be something like this:
tar -I lz4 -pxf foo.tlz4 foo
This was happening because tar.plugin is just substituting on the
first - in "tar -pxf". This works fine if we just add a simple flag for
extraction (eg, z for .tgz), but for lz4 we need to add "-I lz4".
I don't believe that there is an obvious good way to fix this without
reworking the way the command is generated. Probably we should collect
the command and flags separately and the flags should be stored in a
set. Then put everything together into a string just before issuing it
as an extraction command. Unfortunately, this might break things for users
because they have access to tar_extractcmd.
This patch just makes the substitution a little bit more clever so that it
does the right thing when substituting on a string like "tar -pxf".
(2) .tar.lz4 extractions had the same issue, which my patch fixes in
the same way.
(3) .tar.lz4 extractions had another issue. There was a space missing
in the command generated by tar#Extract. This meant that commands
looked like this (notice the lack of space between the archive and output
file names):
tar -I lz4pxf foo.tar.lz4foo
This patch just puts a space where it should be.
Finally, I should note that ChatGPT 5.4 initially identified this issue
in the code and generated the test cases. I reviewed the test cases,
wrote the patch, and actually ran vim against the tests (both with and
without the patch).
closes: vim/vim#1992578954f86c2
Co-authored-by: Aaron Burrow <burrows@fastmail.com>
Problem: runtime(zip): may write using absolute paths
(syndicate)
Solution: Detect this case and abort on Unix, warn in the documentation
about possible issues
46f530e517
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: Commands that rely on Git may need its version to perform more
targeted actions (like decide which arguments are safe to use).
For performance, computing this version is delayed up until it is
needed (like to not compute on regular startup), but not done before
every Git operation (as it is too much and can be done better).
This requires storing the Git version in a variable which is currently
initiated via `vim.version.parse()` call (most probably because it was
easier to handle Lua types this way).
However, the problem is that this results in sourcing `vim.version`
and computing `vim.version.parse` on every startup even if no Git
operation would be done.
Solution: Don't call `vim.version.parse()` during `require('vim.pack')`
and ensure its more precise lazy computation.
Problem:
Running `:Open` on an open buffer does not run `vim.ui.open()` on that file, requiring the user to type `:Open %`. This is inconsistent with most other vim commands which accept files, which default to the current buffer's file.
Solution:
Default to the current file when `:Open` is used without arguments.
Problem:
Opening .tar.gz or .zip URLs shows raw binary instead of using the archive plugins.
Solution:
Similar to the original netrw implementation, the autocmd should detect
archive URLs, download them to a temp file and the open them with
tar/zip handlers already bundled as vim plugins.
Problem:
Apparently vim.SystemCompleted.stdout can also be nil, even without a
custom stdout handler. (Although the docs can be interpreted otherwise).
Solution:
Explicitly check for nil and set the result body to an empty string if
stdout was nil.
Problem: Computing number of threads for parallel asynchronous
computation using `uv.cpu_info()` can be slow. This is especially
noticeable since it is pre-computed on every `require('vim.pack')` and
not only when parallelism is needed.
Solution: Use `uv.available_parallelism()` to compute number of threads
in a helper function.
Problem: When messages are appended to an already expanded cmdline,
the spilled lines indicator is not updated.
Solution: Remove early return for updating virtual text while cmdline is
expanded, guard updating "msg" virt_text at callsite instead.
