Problem: Extmark has support for horizontal scrolling and truncating, but not wrapping.
Solution: Extend virt_lines_overflow flags to support "wrap" and "auto" based on proposed changes in #18282.
Problem: In command-line completion with a popup menu ('wildoptions'
contains "pum"), the info popup shown next to the menu could
not be scrolled, unlike the Insert mode completion info popup
which scrolls with the mouse wheel.
Solution: When the mouse pointer is on top of the info popup, scroll it
with the mouse wheel in command-line mode as well, without
closing the completion popup menu.
closes: vim/vim#20146closes: vim/vim#2041896dbab257a
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
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.
Problem: [security]: another possible code execution with python complete
(David Carliez)
Solution: Strip default expressions and annotations from generated
source for pythoncomplete and python3complete.
Github Security Advisory:
https://github.com/vim/vim/security/advisories/GHSA-65p9-mwwx-7468c8c63673bc
Co-authored-by: Christian Brabandt <cb@256bit.org>
This was originally used because we needed a lua interpreter to run the
standalone _busted_ lua application (except we used fuckery behind the
scenes to fake its binary dependencies with our own binary
dependencies). Now we longer do that, we instead run `test.harness` as a
standard nvim -l script. as this mode is no longer used in tests it
risks going to bitrot anyway.
NB: -ll mode still had some theoretical benefits like quicker
initialization and more "native" printing behavior, etc.
But we can incrementally work on "nvim -l" mode instead
of maintaining a separate special thing.
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.
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 <>
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.
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`.)
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.
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.
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.
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
Add float16_t, float32_t, float64_t, float128_t and bfloat16_t from
<stdfloat> as cppType under a new cpp_no_cpp23 guard.
fixes: vim/vim#16498closes: vim/vim#20367fd30a736cc
Co-authored-by: Yasuhiro Matsumoto <mattn.jp@gmail.com>
Move const, volatile, restrict and _Atomic to a new cTypeQualifier group
and inline and _Noreturn to cFunctionSpec. Add the C23 standard attributes
deprecated, fallthrough, maybe_unused, nodiscard, unsequenced and
reproducible as cStandardAttribute, and reclassify the existing noreturn
into the same group.
The new groups link to cStorageClass, so the default highlighting and any
existing cStorageClass override are unchanged, while allowing finer-grained
customization.
fixes: vim/vim#19574closes: vim/vim#2036877b2376769
Co-authored-by: Yasuhiro Matsumoto <mattn.jp@gmail.com>
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#20032closes: vim/vim#2019138d9a16eba
Co-authored-by: Peter Kenny <github.com@k1w1.cyou>
Problem: The security patch 9.2.0561 added a vim.eval() call inside
Completer.evalsource() to honor g:pythoncomplete_allow_import.
But the 'vim' module is only imported inside the outer
vimcomplete() / vimpy3complete() function, not at the script's
top level, so referring to it from a Completer method raises
NameError. The surrounding bare 'except' silently swallows
the error and leaves allow_imports at 0, meaning the opt-in
never takes effect -- 'import os' (and any other
buffer-level import) is always skipped, no candidates are
produced for 'os.<...>' and
Test_popup_and_preview_autocommand() fails on the Windows
CI matrix (Linux skips the test because Python 2 is absent).
Solution: Re-import 'vim' at the top of evalsource() in both
pythoncomplete.vim and python3complete.vim so the eval reads
the global, and set g:pythoncomplete_allow_import = 1 in the
test (it is the opt-in intended for callers that trust the
buffer contents) (thinca).
closes: vim/vim#20386868ad62cb8
Co-authored-by: thinca <thinca@gmail.com>
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#20370dec3d6c7da
Co-authored-by: KnoP-01 <knosowski@graeffrobotics.de>
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.
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.
