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.
Problem: test: trailing spaces used in tests
Solution: Rewrite tests to avoid trailing spaces (Paul Ollis).
Some tests currently rely on trailing whitespace at the end of lines,
escaped with '\'. I have demonstrated in another PR, such spaces can be
inadvertently removed and this is difficult to spot.
Note: there are more trailing spaces in a few more test files, see
testdir/test_codestyle.vim. Those are not yet removed.
closes: vim/vim#19838211ceea602
Co-authored-by: Paul Ollis <paul@cleversheep.org>
Problem:
failures in s390x CI.
Solution:
- runtime/lua/man.lua: parse_path() can return nil but 3 callers didn't handle it.
- skip some tests on s390x.
TODO:
- TODO: why "build/bin/xxd is not executable" on s390x?
- TODO: other failures, not addressed (see below).
OTHER FAILURES:
FAILED test/functional/treesitter/fold_spec.lua @ 87: treesitter foldexpr recomputes fold levels after lines are added/removed
test/functional/treesitter/fold_spec.lua:95: Expected objects to be the same.
Passed in:
(table: 0x4013c18940) {
[1] = '0'
[2] = '0'
[3] = '0'
*[4] = '0'
[5] = '0'
...
Expected:
(table: 0x4005acf900) {
[1] = '0'
[2] = '0'
[3] = '>1'
*[4] = '1'
[5] = '1'
...
stack traceback:
(tail call): ?
test/functional/treesitter/fold_spec.lua:95: in function <test/functional/treesitter/fold_spec.lua:87>
FAILED test/functional/treesitter/select_spec.lua @ 52: treesitter incremental-selection works
test/functional/treesitter/select_spec.lua:63: Expected objects to be the same.
Passed in:
(string) 'bar(2)'
Expected:
(string) 'foo(1)'
stack traceback:
(tail call): ?
test/functional/treesitter/select_spec.lua:63: in function <test/functional/treesitter/select_spec.lua:52>
FAILED test/functional/treesitter/select_spec.lua @ 69: treesitter incremental-selection repeat
test/functional/treesitter/select_spec.lua:82: Expected objects to be the same.
Passed in:
(string) '2'
Expected:
(string) '4'
stack traceback:
(tail call): ?
test/functional/treesitter/select_spec.lua:82: in function <test/functional/treesitter/select_spec.lua:69>
FAILED test/functional/treesitter/select_spec.lua @ 98: treesitter incremental-selection history
test/functional/treesitter/select_spec.lua:111: Expected objects to be the same.
Passed in:
(string) 'bar(2)'
Expected:
(string) 'foo(1)'
stack traceback:
(tail call): ?
test/functional/treesitter/select_spec.lua:111: in function <test/functional/treesitter/select_spec.lua:98>
FAILED test/functional/treesitter/select_spec.lua @ 186: treesitter incremental-selection with injections works
test/functional/treesitter/select_spec.lua:201: Expected objects to be the same.
Passed in:
(string) 'lua'
Expected:
(string) 'foo'
stack traceback:
(tail call): ?
test/functional/treesitter/select_spec.lua:201: in function <test/functional/treesitter/select_spec.lua:186>
FAILED test/functional/treesitter/select_spec.lua @ 216: treesitter incremental-selection with injections ignores overlapping nodes
test/functional/treesitter/select_spec.lua:231: Expected objects to be the same.
Passed in:
(string) ' )'
Expected:
(string) ' foo('
stack traceback:
(tail call): ?
test/functional/treesitter/select_spec.lua:231: in function <test/functional/treesitter/select_spec.lua:216>
FAILED test/functional/treesitter/select_spec.lua @ 307: treesitter incremental-selection with injections handles disjointed trees
test/functional/treesitter/select_spec.lua:337: Expected objects to be the same.
Passed in:
(string) 'int'
Expected:
(string) '1}'
stack traceback:
(tail call): ?
test/functional/treesitter/select_spec.lua:337: in function <test/functional/treesitter/select_spec.lua:307>
ERROR test/functional/treesitter/parser_spec.lua @ 562: treesitter parser API can run async parses with string parsers
test/functional/treesitter/parser_spec.lua:565: attempt to index a nil value
stack traceback:
test/functional/testnvim/exec_lua.lua:124: in function <test/functional/testnvim/exec_lua.lua:105>
(tail call): ?
(tail call): ?
test/functional/treesitter/parser_spec.lua:563: in function <test/functional/treesitter/parser_spec.lua:562>
FAILED test/functional/core/job_spec.lua @ 1157: jobs jobstop() kills entire process tree #6530
test/functional/core/job_spec.lua:1244: retry() attempts: 94
test/functional/core/job_spec.lua:1246: Expected objects to be the same.
Passed in:
(table: 0x401dd74b30) {
[name] = 'sleep <defunct>'
[pid] = 33579
[ppid] = 1 }
Expected:
(userdata) 'vim.NIL'
stack traceback:
test/testutil.lua:89: in function 'retry'
test/functional/core/job_spec.lua:1244: in function <test/functional/core/job_spec.lua:1157>
Problem:
The "restart" event has some problems:
- all UI clients must implement a somewhat complex set of setups
- UI must be on the same machine as the server
- only works for the "current" UI
- race/edge case: If the user config has errors / waiting for input, are
all UIs able to attach while Nvim is waiting for input?
Solution:
- Perform the restart on the server, not the client.
- Pass listen address (instead of CLI args) in the UI event.
- Simplifies UI logic: they only need to attach to new address.
- Opens the door for more enhancements in the future, such as allowing
all UIs to reattach instead of only the "current" UI.
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Problem:
- Progress-events are filtered by "source". But "source" is not required by nvim_echo.
- Without "++nested" (force=false), nvim_echo in an event-handler does not trigger Progress events.
- vim.health does not declare a "source".
Solution:
- Make source mandatory for progress-messages
- Enable ++nested (force=true) by default when firing Progress event.
- Set "source" in vim.health module.
Problem: setting one underline style to false clears bits belonging
to another style. `{underdouble = true, underdashed = false}` results
in undercurl because CHECK_FLAG_WITH_KEY does `m &= ~flag` which
doesn't work for multi-bit encoded values sharing HL_UNDERLINE_MASK.
Solution: use a local variable to derive the correct clear mask from
the flag. Clear the whole HL_UNDERLINE_MASK field instead of individual
bits, and only clear on false when the current style actually matches.
Problem:
Currently, we recommend always inserting text above prompt-line in
prompt-buffer. This can be done using the `:` mark. However, although
we recommend it this way it can sometimes get confusing how to do it
best.
Solution:
Provide an api to append text to prompt buffer. This is a common
use-case for things using prompt-buffer.
Problem: Progress reports via `nvim_echo()` gained an ability to set
`source` and `vim.pack` doesn't currently set one.
Solution: Set `source` to 'vim.pack'. Ideally, the title then can be
something else more informative (like "update", "download", etc.), but
it is used when showing progress messages. So it has to be "vim.pack"
in this case.
Problem:
When running nvim in headless mode with `cmdheight=0`, an extra newline
is prepended to output (eg. `nvim --clean --cmd 'set cmdheight=0'
--headless -c 'echo 1 | q' ` prints `\n1` instead of `1`), because
`!ui_has(kUIMessages)` is always true in headless mode, causing `p_ch ==
0` in `msg_start()` to unconditionally trigger `msg_putchar('\n')` which
writes a newline to stdout.
Solution:
When in headless printf mode with `p_ch == 0` and no prior output on the
current line, call `msg_puts_display("\n", ...)` directly instead of
`msg_putchar('\n')`, so the grid is still updated for correct screen
positioning but no newline is written to stdout.
Problem:
Currently, there's no way to distinguish progress messages coming from
different sources. Nor can Progress event be easily filtered based on
source.
Solution:
- Add "source" field to nvim_echo-opts.
- The Progress event pattern is now defined by the "source" field.
- Include the "title" as ev.data.
- Unrelated change: set force=false to disable nesting.
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.
Problem: When entering the cmdline below expanded messages, those
messages are moved to the dialog window. The dialog window
supports paging but that is unexpected in this situation where
it just serves to keep (some of, exactly those that were
visible before the cmdline was entered) the messages visible.
Wrong highlight group for dialog "more" message.
Solution: Don't create the `vim.on_key()` dialog pager callback after
entering the cmdline below expanded messages.
Use the MsgMore highlight group for the paging hint title.
Problem:
Currently we are using
if 1 item then
{title}: {percent}%
else
Progress: {AVG}%({N})
dropping {title} and Progress text saves up space in statusline plus makes the format consistent, less jumping around.
Solution:
Use `{AVG}%({N})` for all cases.
Problem: nvim_set_hl always replaces all attributes.
Solution: Add update field. When true, merge with existing
attributes instead of replacing. Unspecified attributes are preserved.
If highlight group doesn't exist, falls back to reset mode.
- Highlight keywords "function" and "namespace" with
the "Keyword" group ("shFunctionKey").
- Highlight function body delimiters "{" and "}" with the
"Delimiter" group ("shFunctionExprRegion").
- Highlight function body delimiters "(" and ")" with the
"Operator" group ("shFunctionSubShRegion").
- Also, follow one style in folding all supported variants
of function bodies for grouping commands too by enclosing
a delimited function body, e.g. "{" and "}", in a fold and
leaving its function header, e.g. "function f()", out of
it when the header is written on a separate line.
To restore previous colouring, add to "after/syntax/sh.vim":
------------------------------------------------------------
hi link shFunctionKey Function
hi link shFunctionExprRegion Function
hi link shFunctionSubShRegion Function
------------------------------------------------------------
fixes: https://github.com/vim/vim/pull/19638#issuecomment-4052635546closes: vim/vim#19638955c02dff7
Co-authored-by: Aliaksei Budavei <0x000c70@gmail.com>
Problem: JSON files should end with a trailing newline so that Unix
tools work as expected, Git doesn't report "No newline at end of file"
and to avoid noise in diffs from editors and other tools adding the
missing newline.
Solution: Add trailing newline.
Problem: - With expanded messages exceeding cfg.msg.cmd.height, entering
the cmdline scrolls to the bottom and expands to the full "cmd"
buffer text height.
- Cursor in the pager is not always at the last message and at
the bottom of the window when appending to the pager.
- unreliable test: messages2_spec: "closed msg window timer removes
empty lines".
Solution: - Achieve separation of the cmdline and message text by moving
messages to the dialog window when entering the cmdline below
expanded messages.
- Set cursor to start of the first message only when first
entering the pager. Use `norm! zb` to position last message
at the bottom of the window (which shouldn't crash anymore
since 911337eb).
- Increase cfg.msg.msg.timeout used in the test file.
Problem:
Currently same progress stat get's displayed on statusline of all
windows. This is repeatitive and noisy.
Solultion:
Only display progress-status on the focused window
Problem:
Currently, when multiple progress are on going we show it as Progress:
{N} items {percent}% format. It can be simplified sinnce items doesn't
really add enough value for the valuable space it takes in statusline
Solution:
Change format to Progress: {percent}%({N})
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 `..`
Problem: clangd prepends a space/bullet indicator to label. With
labelDetailsSupport enabled, the signature moves to labelDetails,
making label shorter. This flips the length comparison in
get_completion_word, causing it to use item.label directly and
insert the indicator into the buffer.
Solution: only prefer filterText over label when label starts with non-keyword
character in get_completion_word fallback branch.
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.
Problem: Generating snippet preview in get_doc() populated the
documentation field before resolve, so the resolve request was
never sent.
Solution: Move snippet preview logic into on_completechanged and
the resolve callback so it no longer blocks the resolve request.
Problem:
The "tohtml" plugin is loaded by default.
Solution:
- Move it to `pack/dist/opt/nvim.tohtml/`, it is an "opt-in" plugin now.
- Document guidelines.
- Also revert the `plugin/` locations of `spellfile.lua` and `net.lua`.
That idea was not worth the trouble, it will be too much re-education
for too little gain.
Problem: No 'incsearch' highlighting support for :uniq
Solution: Add :uniq support (Hirohito Higashi)
closes: vim/vim#1978048137e4e48
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
Problem:
libmpack encodes boundary values -129 and -32769 with wrong integer
sizes:
- -129 as int8 instead of int16
- -32769 as int16 instead of int32
because the boundary checks compare against the wrong values (e.g., lo
< 0xffffff7f instead of lo < 0xffffff80). This caused data corruption:
-129 would decode as 127.
Solution:
Fix off-by-one errors in the two's complement boundary constants:
0xffffff80 (-128, min int8) and 0xffff8000 (-32768, min int16).
Fixes#37202
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
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`.
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.
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%"
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).
Introduce _provider_foreach to iterate over all matching provider
capabilities for a given LSP method, handling both static and dynamic
registrations. Update diagnostic logic and tests to use the new
iteration approach, simplifying capability access and improving
consistency across features.
Problem
Unlike inlay hints, code lenses are closely related to running commands;
a significant number of code lenses are used to execute a command (such
as running tests). Therefore, it is necessary to provide a default
mapping for them.
Solution
Add a new default mapping "grx" (mnemonic: "eXecute", like "gx").
