Problem:
Vimscript ftplugins that inherit a base ftplugin often use explicit
`runtime! ftplugin/foo.vim` patterns. This skips corresponding Lua
ftplugins, unlike top-level ftplugin loading.
Solution:
Use the existing `{vim,lua}` patterns for bang runtime imports while
preserving each call's current lookup breadth.
Problem:
This functions are most likely never used in the wild.
- They are redundant with `nvim_get_context` + `nvim_load_context`.
- The "context" concept was never fully developed and hasn't gained
traction.
Solution:
Drop these vimscript aliases, they are just extra cruft.
Problem:
`FileType directory` fires *before* the `BufEnter` path where `dir.lua`
populates the buffer, in order to allow a 3P dir-browser plugin to handle the
event and (optionally) rename the buffer to e.g. `example:///tmp/foo/`.
But currently, `open_buffer()` continues after `filetypedetect BufRead` as if
the original directory buffer is *still* current and valid, which may fall
through to the built-in `nvim.dir` path after a 3P plugin ALREADY handled the
directory.
Solution:
Keep a buf ref around the early `filetypedetect BufRead` call for directory
buffers.
If the `FileType directory` handler switches away from/deletes the original
directory buffer, stop the open path instead of continuing into the built-in
`nvim.dir` flow.
Problem:
After 25439dad7e, `opts` is optional, but not params that follow it.
Solution:
- Update `gen_api_dispatch.lua`, docs, tests.
- Enhance the `nvim_get_api_info()` api-metadata to include a boolean
flag indicating whether a parameter is optional:
```
[type, name, optional]
```
Note: Currently, optional params are assumed to be Dict/Array. Since we
don't yet have any use-cases of optional params following `opts`, the
build just checks this assumption and we can deal with it later if we
ever care to:
nvim_get_hl: optional param "foo" has type "Integer" but (currently)
we assume Dict/Array
FAILED …/plugin/pack_spec.lua:92: …/plugin/pack_spec.lua @ 70: vim.pack update() can use lockfile revision as a target
…/plugin/pack_spec.lua:92: …/plugin/pack_spec.lua:70: process still exists
stack traceback:
D:/a/neovim/neovim/test/functional/testnvim/exec_lua.lua:124: in function 'system_sync'
…/plugin/pack_spec.lua:92: in function 'git_cmd'
…/plugin/pack_spec.lua:113: in function 'git_add_commit'
…/plugin/pack_spec.lua:1209: in function <…/plugin/pack_spec.lua:1173>
fix#40167
Problem:
|api-contract| allows adding an optional trailing `opts` parameter, but
the dispatch generator still requires every parameter, so `opts` cannot
be omitted.
Solution:
Treat a trailing `Dict(...) *opts` parameter as optional in the generated
RPC and Lua dispatch wrappers.
Co-authored-by: Judit Novak <judit.novak@gmail.com>
Problem:
A successful `BufReadCmd` can leave an existing `filetype` without
rerunning its `FileType` setup, so state cleared during reload may not
be restored.
This also causes `:edit`/reload syntax `directoryDirectory` groups to
not be reapplied.
Solution:
After `BufReadCmd` handles a read, trigger `FileType` for the existing
`filetype` if no `FileType` event fired during the read.
Problem:
Continue separators normalization, and try to keep it at the
nvim <-> external boundary, e.g., `fn.xxx`, `api.xxx`, `:xxx`
Solution:
some key changes
- normalize `$HOME-windows`
- normalize entry points of changing directory
- `nvim_set_current_dir()`, `chdir()`
- normalize the named pipe
- `--listen` arg, `--server` arg, `:restart`
- `serverstart()`, `sockconnect()`, `serverstop()`
- make `expand()` respect 'shellslash' again
- clean up `did_set_shellslash`
- replace `forward_slash` with `TO_SLASH`
- remove obsolete `TMP_PATHSEPSTR`
- remove `slash_adjust` in `do_autocmd_dirchanged`?
- make `fnamemodify()` always return `/` (except when substituting
separators via `:s`, `:gs` ?)
Note:
- these funcs still apply `slash_adjust` on return, as before:
`:pwd`, `chdir()`, `exepath()`, `getcwd()`
- these funcs alwarys return `/`, unlike before the normalization PRs
- `getcompletion()`, `finddir()`, `findfile()`
Also
- clean up code, comments, formatting and tests
- move `TO_SLASH` from `f_chdir` to `changedir_func`
- move `TO_SLASH` from `f_bufadd` to `buflist_new`
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Problem:
Malformed server responses with `null` (vim.NIL) values, do not show
clear error messages.
Solution:
Assert two known, specific cases, to avoid user confusion.
Problem: When a split window is created from the init script using nvim_open_win()
with enter=false, the current window focus is not preserved. The cursor
incorrectly moves into the newly created split during startup.
Solution: Save curwin before the iteration loop in create_windows(), and
restore it after the loop. also update edit_buffers() to use curwin instead
of firstwin.
Problem:
- `edit.c` is an unnecessarily misleading and less-discoverable name
than `insert.c`.
- Numerous insert-mode related things are named with a `ins_` prefix.
- There is already a `insexpand.c` module...
Solution:
Rename `edit.c` => `insert.c`.
Problem:
`getchar.c` is a quirky name and doesn't align with our existing
`os/input.c` and `tui/input.c` modules, which encompass the same topic
at different layers.
Solution:
Rename `getchar.c` => `input.c` for discoverability.
Introduce `dialog.c` for functionality related to showing confirm
prompts, dialogs, etc.
Problem:
URI buffer names can end with a slash, but slash-ended directory
matching should not preempt URI filetype patterns.
Solution:
Do not use the slash shortcut for names with URI schemes, so those
continue through normal filetype matching.
Co-authored-by: Adam Karafyllidis <akisarou90@gmail.com>
FAILED 2 tests, listed below:
FAILED …/lua/system_spec.lua:124: …/lua/system_spec.lua @ 44: vim.system (async) supports timeout
…/lua/system_spec.lua:124: …/lua/system_spec.lua:44: process still exists
stack traceback:
D:/a/neovim/neovim/test/functional/testnvim/exec_lua.lua:124: in function 'system'
…/lua/system_spec.lua:124: in function <…/lua/system_spec.lua:118>
FAILED …/lua/system_spec.lua:111: …/lua/system_spec.lua @ 22: vim.system (sync) can set environment with clear_env = true and env = nil
…/lua/system_spec.lua:111: …/lua/system_spec.lua:22: process still exists
stack traceback:
D:/a/neovim/neovim/test/functional/testnvim/exec_lua.lua:124: in function 'system'
…/lua/system_spec.lua:111: in function <…/lua/system_spec.lua:97>
Problem:
unreliable test:
FAILED …/tui_spec.lua @ 895: TUI mouse events work with right-click menu (escape sequences sent to child)
D:/a/…/testnvim.lua:144: Vim:Failed to start server: address already in use
stack traceback:
D:/a/…/testnvim.lua:144: in function 'eval'
D:/a/…/testnvim.lua:1015: in function 'new_pipename'
…/tui_spec.lua:897: in function <…/tui_spec.lua:895>
Solution:
Workaround potential PID reuse.
Problem:
Changing global 'winbar' only updates window layout state in the current
tabpage. This means existing hidden tabs can keep stale winbar height.
Solution:
Recompute winbar state for all tabpages on global `'winbar'` changes.
Problem:
`vim.filetype.match()` needs a cheap way to recognize directory buffers
without doing filesystem stat work.
Solution:
Ensure full buffer names for directories end in a trailing slash. Now
directory buffers can proceed through the normal 'filetype' path.
Note side-effects: session and ShaDa buffer-list restore behavior must
be compatible, so those + corresponding tests must be updated.
unify context-switching logic.
1. `prevwin` is now restored for all targets (was buf-only).
- add a `nvim_win_call` test.
2. The buf-found "restore the shown buffer" dance no longer depends on
the origin window: it runs even if the callback closed the origin.
Problem:
`screen:expect({none=…})` with no any/grid crashed (concat on nil)
because actual_rows was only rendered when any or grid was present.
Solution:
Update the condition.
Problem:
A `--listen` path longer than the system socket path limit (~104 bytes on
macOS, 108 on Linux) is silently truncated by `uv_pipe_bind()`. Nvim either
serves a socket at a different path than `v:servername` reports, or fails with
an error that blames the full untruncated path (confusing):
nvim: Failed to --listen: address already in use: "<full path>"
Steps to reproduce:
$ nvim --listen /var/folders/g7/9y_ydbnj2fs_fvp8xf44p8gc0000gn/T//nvim/-Users-rpatterson-Projects-src-github.com-neovide-neovide --embed -p
nvim: Failed to --listen: address already in use: "/var/folders/g7/9y_ydbnj2fs_fvp8xf44p8gc0000gn/T//nvim/-Users-rpatterson-Projects-src-github.com-neovide-neovide"
$ ls /var/folders/g7/9y_ydbnj2fs_fvp8xf44p8gc0000gn/T//nvim/-Users-rpatterson-Projects-src-github.com-neovide-neovide
"/var/folders/g7/9y_ydbnj2fs_fvp8xf44p8gc0000gn/T//nvim/-Users-rpatterson-Projects-src-github.com-neovide-neovide": No such file or directory (os error 2)
$ ls -l /var/folders/g7/9y_ydbnj2fs_fvp8xf44p8gc0000gn/T//nvim/
srwxr-xr-x@ - rpatterson 31 Mar 10:24 -Users-rpatterson-Projects-src-github.com-neovid
Solution:
Bind with `uv_pipe_bind2()` and `UV_PIPE_NO_TRUNCATE` (libuv 1.46+), so
a too-long path fails up front with the actual reason:
nvim: Failed to --listen: invalid argument: "<full path>"
Problem: No concise way to execute a callback with temporarily set
working directory. This might be useful when sourcing nested files to
allow them to assume that current working directory is their root
directory.
Solution: Add `cwd` context to `vim._with().`
Problem: when an LS client detaches from the buffer, only pull diagnostics
are cleared via capability framework. Push diagnostics remain stuck even
when client stops/restarts.
Solution: clear push diagnostics on client detach.
ref #33864
When a server supports both document and workspace pull diagnostics,
`on_refresh` only dispatched a `workspace/diagnostic` request. The
workspace response handler skips buffers with `pull_kind == "document"`
(i.e. all buffers opened by the user), so their diagnostics went stale
until the next `didChange` or `didOpen` event.
Change `on_refresh` to always refresh document-pull buffers via
`textDocument/diagnostic`, regardless of whether the server also
supports workspace diagnostics. This ensures that opened buffers
see updated diagnostics (e.g. after a save triggers an external
tool like PHPStan) without requiring the user to re-enter insert
mode.
Problem: The codelens LSP module was using its own raw buffer events and
its own debounce mechanism for refreshing code lens in attached buffers.
Solution: Switch the module to using the LspNotify autocmd events.
LspNotify fires just after document versions are synced with the server
and provides a built in debounce mechanism for changes.
Additionally, this fixes some bugs with the previous implementation:
1. The workspace/codeLens/refresh handler re-requested codelens for all
buffers but when the response came back, it forced an extra redraw
after clearing the work the handler had just done.
2. Document synchronization was reworked to be more resilient to
multiple clients providing codelens for a single buffer. The latest
document version is now separately tracked per client (and per
client's lenses per row) instead of for the buffer as a whole. This
allows the on_win() function to properly redraw all codelens even
when different clients' responses for a particular document version
come back at different times.
Problem:
bufwrite message overridden by :redrawstatus command within Progress callback.
Solution:
- don't use globally-shared IObuf.
- use vim_snprintf to deduplicate `nlua_call_luaeval`, `nlua_call_vlua`.
fix https://github.com/neovim/neovim/issues/40616
Problem:
Clearing a register via `:let @a = ""` doesn't persist in shada.
Solution:
Follows the precedent of ee56daebb6 .
Namely, when the live register is empty and *at least as recent* as the copy
that is on disk, drop it instead of writing it back.
Problem:
`:let @/ = ""` doesn't stick after restart (the old search pattern comes back).
Solution:
When the current session cleared the pattern more-recently than stored
shada entry, drop the shada entry instead of restoring it.
Note: similar timestamp-based suppression was used for deleted
marks: ee56daebb6
Problem:
Neovim can permanently stop accepting keyboard input after a large paste, or after
any sufficiently large input burst. The screen still redraws and honours window
resize, but typed keys have no effect and the session must be killed. A paste that
triggers the freeze is applied only partially.
Root cause:
`src/nvim/os/input.c` holds `input_buffer[INPUT_BUFFER_SIZE]` (16386 bytes),
compacted left rather than used as a ring:
- `input_get()` drains the buffer by advancing `input_read_pos`, but never rewinds
the cursors when it empties (`input_read_pos == input_write_pos`).
- The only rewind lives in `input_enqueue_raw()`, which `input_enqueue()` reaches
only inside `while (input_space() >= 19 && ptr < end)` (19 is the maximum
expansion of one `<x>` key form).
So once input fills the buffer to within 19 bytes of the top and is then fully
drained, the cursors are pinned near the top with `input_space() < 19`. The gate
never reopens, `input_enqueue()` never rewinds, and all further input is silently
dropped: `input_available()` stays 0 and the editor blocks forever in
`state_enter()` → `input_get()`. Redraw and resize run on independent paths, which
is why the UI looks alive while the keyboard is ignored.
Solution:
Rewind the read/write cursors when the buffer is empty, at the start of
`input_enqueue()`. The reset moves no data in the empty case and guarantees the
space gate can reopen; the non-empty case self-heals as the editor drains.
Test case:
A reproducer (no terminal required; drives `nvim --embed` over msgpack-RPC via
`nvim_input`) floods the input buffer, lets the editor drain it, then probes with
`:qa!`. It shows a sharp threshold at `INPUT_BUFFER_SIZE − 18`:
| `--fill` | master | with this fix |
|----------|-----------|---------------|
| ≤ 16367 | quits | quits |
| ≥ 16368 | **hangs** | quits |
- On current `master`, the freeze reproduces at `fill=16368`; the patched build
quits for every fill up to 100000.
- Interactive: a ~40 kB bracketed paste into Insert mode or a `:terminal` no longer
freezes.
Problem:
Session files specified at startup `-S [file]`, logically conflict
with `:restart`.
Solution:
Remove `-S [file]` from `v:argv` when doing :restart.
Also for the "bang" variant `:restart!`, just because it's
simpler (if anyone reports a use-case later, we can revisit).
Problem:
Inlay hints used separate global and per-buffer bufstates tables and
bespoke global autocmds for managing the inlay hint state across buffers
and clients, duplicating the lifecycle logic already provided by the
Capability framework. This caused inconsistencies in how client state
was handled and inlay hint state lifecycle was managed compared to other
LSP features.
Solution:
Replace the ad-hoc bufstate tracking and global autocmds in
vim.lsp.inlay_hint with a proper InlayHint subclass of Capability.
This also refactors the way inlay hint state is managed and fixes bugs I
found while doing this:
1. For each line with inlay hints, the list of the hints along with
whether they have been applied is stored in a current result on the
client state. This allows the on_win decorator to clear all inlay
hints for an old document version once, and then re-add the new
version's hints line-by-line as they are drawn to the screen,
modeling the semantic tokens module.
2. It fixes problems with mixing results from multiple clients attached
to the buffer by fully moving each client's state to its own table.
Previously, only the most recent document version used to populate a
line's inlay hints was stored, but there was no distinction for which
client the hints may have come from. (Fixes#36318)
3. It fixes the workspace/inlayHint/refresh server->client notification
behavior. Previously it would only re-request inlay hints for buffers
currently displayed in a window but would not invalidate them in
non-displayed buffers (or provide any mechanism for those buffers to
re-request at a later time). Model semantic token module here again
by invalidating all buffers, and adding a BufWinEnter autocmd to
refresh hints.
4. Add a mechanism to cancel in-flight requests if a new request for a
newer document version is made before the last one returned
5. Handle stale results by simply dropping them.
