Problem: Visual block insert on a single line incorrectly triggers two
on_lines callbacks - one for the correct line (0-indexed) and another
for a non-existent additional line.
Solution: Only call changed_lines() in block_insert() when additional
lines beyond the first were actually modified (start.lnum < end.lnum).
Problem:
It's relatively easy to mispress key `a` to (a)llow arbitrary execution
of 'exrc' files. #35050
Solution:
- For exrc files (not directories), remove "allow" menu item.
Require the user to "view" and then explicitly `:trust` the file.
Problem:
diagnostic extmark used for positioning continues to exist after
deleting a range containing it, so it's possible to jump to a
next/previous diagnositc, which isn't visible in any way, including not
being shown via `open_float`.
Solution:
enable `invalidate` flag when setting an extmark to be able to filter
out diagnostics based on `invalid` flag when looking for next/previous
diagnostic to jump to.
When right_gravity is set to true for deactivating tabstop expansion we
have to set end_right_gravity to false to avoid expanding the tabstop
region on the right side. Vice versa for activating tabstop expansion
again.
Problem:
Diagnostic positions are not being updated after text changes, which
means `vim.diagnostic.open_float` and `vim.diagnostic.jump` will work
with outdated positions when text is changed until diagnostics are
updated again (if ever).
Solution:
Create extmarks in `vim.diagnostic.set` and use their positions for
`vim.diagnostic.open_float` and `next_diagnostic` (used by
`vim.diagnostic.jump`, `vim.diagnostic.get_next` and
`vim.diagnostic.get_prev`).
Problem: After filtering out all elements, ArrayIter:last still returns a stale element.
Solution: Add check for self._head == self._tail and return nil early.
Fix#34696
Problem:
Nvim depends on netrw to download/request URL contents.
Solution:
- Add `vim.net.request()` as a thin curl wrapper:
- Basic GET with --silent, --show-error, --fail, --location, --retry
- Optional `opts.outpath` to save to a file
- Operates asynchronously. Pass an `on_response` handler to get the result.
- Add integ tests (requires NVIM_TEST_INTEG to be set) to test success
and 404 failure.
- Health check for missing `curl`.
- Handle `:edit https://…` using `vim.net.request()`.
API Usage:
1. Asynchronous request:
vim.net.request('https://httpbingo.org/get', { retry = 2 }, function(err, response)
if err then
print('Fetch failed:', err)
else
print('Got body of length:', #response.body)
end
end)
2. Download to file:
vim.net.request('https://httpbingo.org/get', { outpath = 'out_async.txt' }, function(err)
if err then print('Error:', err) end
end)
3. Remote :edit integration (in runtime/plugin/net.lua) fetches into buffer:
:edit https://httpbingo.org/get
Problem:
The "gitsigns" plugin runs `vim.diff` in a thread (`uv.new_work`), but
`vim.diff` is nil in that context:
Lua callback:
…/gitsigns.nvim/lua/gitsigns/diff_int.lua:30: bad argument #1 to 'decode' (string expected, got nil)
stack traceback:
[C]: in function 'decode'
…/gitsigns.nvim/lua/gitsigns/diff_int.lua:30: in function <…/gitsigns.nvim/lua/gitsigns/diff_int.lua:29>
Luv thread:
…/gitsigns.nvim/lua/gitsigns/diff_int.lua:63: attempt to call field 'diff' (a nil value)
Solution:
Revert the `stdlib.c` change (set `vim.diff` instead of `vim._diff`).
Problem:
Since renaming `vim.diff` to `vim.text.diff`, `thread_spec.lua` fails in
the zig build. Is `vim.text.diff` not available in the thread context?
Why does it only fail in the zig build?
FAILED ./test/functional/lua/thread_spec.lua @ 217: thread vim.* diff
./test/functional/lua/thread_spec.lua:229: Expected objects to be the same.
Passed in:
(nil)
Expected:
(table: 0x7f221d392218) {
[1] = 'notification'
E5113: Lua chunk:
[2] = 'result'
[3] = {
[1] = '@@ -1 +1 @@
-Hello
+Helli
' } }
stack traceback:
./test/functional/lua/thread_spec.lua:229: in function <./test/functional/lua/thread_spec.lua:217>
FAILED ./test/functional/lua/thread_spec.lua @ 372: threadpool vim.* work
./test/functional/lua/thread_spec.lua:384: Expected objects to be the same.
Passed in:
(table: 0x7f2225be2c30) {
[1] = 'notification'
[2] = 'result'
*[3] = {
*[1] = vim.NIL } }
Expected:
(table: 0x7f2225be25c0) {
[1] = 'notification'
[2] = 'result'
*[3] = {
*[1] = '@@ -1 +1 @@
-Hello
+Helli
' } }
stack traceback:
./test/functional/lua/thread_spec.lua:384: in function <./test/functional/lua/thread_spec.lua:372>
Solution:
Use `vim._diff` in the test, until a root cause is found.
This commit allows users to jump to the location specified in a
diagnostic's `relatedInformation`, using `gf` from within the
`open_float` window. The cursor need only be on line that displays the
related info.
Problem: Hardcoded highlight IDs for ext_messages/cmdline output need
to be adjusted everytime a builtin highlight group is added.
Solution: Store a global map of default highlights through nvim_get_hl()
and fetch missing (custom) highlight groups through synIDattr().
Use more compact formatting for screen:expect().
Problem: Unable to tell whether msg_history_show event is emitted for a
:messages or g< command.
Solution: Add "prev_cmd" argument that is set to true for g<.
Make `vim.iter():take()` and `vim.iter():skip()`
optionally accept predicates to enable takewhile
and skipwhile patterns used in functional
programming.
731e616a79 made it so passing `{env = nil, clear_env = true }` would
pass `{env = {}}` to `vim.uv.spawn`.
However this is not what `clear_env` is (arguably) supposed to do.
If `env=nil` then that implies the uses wants `vim.uv.spawn()` to use
the default environment. Adding `clear_env = true` simply prevents
`NVIM` (the base environment) from being added.
Fixes#34730
Problem: No way to compute intersection of two version ranges, which is
useful when computing version range that fits inside several reference
ranges.
Solution: Add `vim.version.intersect()`.
Problem: `vim.version.range('<=a.b.c')` is not precise when it comes to
its right hand side. This is due to version ranges using exclusive right
hand side. While `vim.version.range('>a.b.c')` is not precise when it
comes to its left hand side because left hand sides are inclusive.
Solution: For '>=a.b.c' increase `to` from 'a.b.c' to the smallest
reasonable version that is bigger than 'a.b.c'. For '<a.b.c' do the same
for `from`.
More proper solution is an explicit control over inclusivity of version
range sides, but it has more side effects and requires design decisions.
Problem: `tostring()` applied to version range doesn't return
human-readable text with information about the range.
Solution: Add `__tostring()` method.
Problem: ext_messages cannot tell when the screen was cleared, which is
needed to clear visible messages. An empty message is also
never emitted, but clears messages from the message grid.
Solution: Repurpose the "msg_clear" event to be emitted when the screen
was cleared. Emit an empty message with the `empty` kind to
hint to a UI to clear the cmdline area.
Problem:
In setup_env, some needed logic is bypassed when clear_env=true.
Solution:
Drop the early return in setup_env().
Co-authored-by: BirdeeHub <birdee@localhost>
Problem: ext_messages is implemented to mimic the message grid
implementation w.r.t. scrolling messages, clearing scrolled
messages, hit-enter-prompts and replacing a previous message.
Meanwhile, an ext_messages UI may not be implemented in a way
where these events are wanted. Moreover, correctness of these
events even assuming a "scrolled message" implementation
depends on fragile "currently visible messages" global state,
which already isn't correct after a previous message was
supposed to have been overwritten (because that should not only
happen when `msg_scroll == false`).
Solution: - No longer attempt to keep track of the currently visible
messages: remove the `msg_ext(_history)_visible` variables.
UIs may remove messages pre-emptively (timer based), or never
show messages that don't fit a certain area in the first place.
- No longer emit the `msg(_history)_clear` events to clear
"scrolled" messages. This opens up the `msg_clear` event to
be emitted when messages should actually be cleared (e.g.
when the screen is cleared). May also be useful to emit before
the first message in an event loop cycle as a hint to the UI
that it is a new batch of messages (vim._extui currently
schedules an event to determine that).
- Set `replace_last` explicitly at the few callsites that want
this to be set to true to replace an incomplete status message.
- Don't store a "keep" message to be re-emitted.
Problem: ml_get error when updating quickfix buffer with nvim_buf_attach
Solution: use correct lnume parameter in changed_lines for append mode
Fix#34610
Problem: Buffer events (specifically on_bytes callbacks) weren't triggered when the
quickfix list was modified, preventing buffer change notifications.
Solution: Add code to send both bytes and lines change notifications after
quickfix buffer updates to properly trigger all attached callbacks.
Problem: The "append" parameter added in abb40ece is missing from
history entries, resulting in different message formatting
for "g<".
Solution: Add "append" field to message history entries.
Co-authored-by: phanium <91544758+phanen@users.noreply.github.com>
Problem:
vim.uv.spawn will emit ENOENT for either when the cmd or cwd do not
exist and does not tell you which.
Solution:
If an error occurs, check if cwd was supplied and included in the error
message if it does not exist.
Problem: Can't use getpos('v') in OptionSet when using setbufvar().
Solution: Don't reset Visual selection when switching to the same
buffer (zeertzjq).
closes: vim/vim#173735717ee33db
Problem: Consecutive "msg_show" events stemming from an `:echon`
command are supposed to be appended without a newline, this
information is not encoded in the "msg_show" event.
Solution: Add an "append" parameter to the "msg_show" event that is set
to true to indicate the message should not start on a new line.
Considered alternative: Emit a newline for the common case instead at the
start of a new message. That way UIs can more closely follow the logic
as it is implemented for the message grid currently. This would be a
breaking change. The "append" parameter seems OK.
|vim.glob.to_lpeg()| uses a new LPeg-based implementation (Peglob) that
provides ~50% speedup for complex patterns. The implementation restores
support for nested braces and follows LSP 3.17 specification with
additional constraints for improved correctness and resistance to
backtracking edge cases.
Problem:
decorations_spec.lua, float_spec.lua, multigrid_spec.lua are not
auto-formatted.
Solution:
Add a special `formatlua2` cmake target, which invokes `stylua` with
an alternative `.stylua2.toml` config.
