Problem:
`:lsp restart` detects when a client has exited by using the `LspDetach`
autocommand. This works correctly in common cases, but breaks when
restarting a client which is not attached to any buffer. It also breaks
if a client is detached in between `:lsp restart` and the actual
stopping of the client.
Solution:
Move restart logic into `vim/lsp/client.lua`, so it can hook in to
`_on_exit()`. The public `on_exit` callback cannot be used for this, as
`:lsp restart` needs to ensure the restart only happens once, even if
the command is run multiple times on the same client.
Problem:
We want to encourage implementing core features in Lua instead of C, but
it's clumsy because:
- Core Lua code (built into `nvim` so it is available even if VIMRUNTIME
is missing/invalid) requires manually updating CMakeLists.txt, or
stuffing it into `_editor.lua`.
- Core Lua modules are not organized similar to C modules, `_editor.lua`
is getting too big.
Solution:
- Introduce `_core/` where core Lua code can live. All Lua modules added
there will automatically be included as bytecode in the `nvim` binary.
- Move these core modules into `_core/*`:
```
_defaults.lua
_editor.lua
_options.lua
_system.lua
shared.lua
```
TODO:
- Move `_extui/ => _core/ui2/`
Problem:
Terminals should respond with the terminator (either BEL or ST) used in
the query so that clients can reliably parse the responses. The
`TermRequest` autocmd used to handle background color requests in the
terminal does not have access to the original sequence terminator, so it
always uses BEL. #37018
Solution:
Update vterm parsing to include the terminator type, then forward this
data into the emitted `TermRequest` events for OSC/DCS/APC sequences.
Update the foreground/background `TermRequest` callback to use the same
terminator as the original request.
Details:
I didn't add the terminator to the `TermResponse` event. However, I
assume the `TermResponse` event doesn't care about the terminator
because the sequence is already parsed. I also didn't update any of the
functions in `src/nvim/vterm/state.c` that write out responses. It
looked like those all pretty much used ST, and it would be a much larger
set of changes. In that same file, there's also logic for 8 bit ST
sequences, but from what I can tell, 8 bit doesn't really work (see `:h
xterm-8bit`), so I didn't use the 8 bit ST at all.
Problem: Deleting active plugins can lead to a situation when it is
reinstalled after restart.
Solution: Suggest "delete" code action only for not active plugins.
Whether a plugin is not active is visible by a hint in its header.
Problem: Using `vim.pack.del()` to delete active plugin can lead to
a situation when this plugin is reinstalled after restart. Removing
plugin from 'init.lua' is documented, but can be missed.
Solution: Make `del()` only remove non-active plugins by default and
throw an informative error if there is an active plugin.
Add a way to force delete any plugin by adding `opts.force`. This also
makes `del()` signature be the same as other functions, which is nice.
Problem: 'fsync' option cannot be set per buffer
Solution: Make 'fsync' option global-local
(glepnir)
closes: vim/vim#190194d5b303726
Co-authored-by: glepnir <glephunter@gmail.com>
Problem: There is now way to run `update()` without Internet connection
while there are some workflows that do not require it. Like "switch
plugin version" and "revert latest update".
Solution: Add `opts.offline` to `update()`. This also allows now to
treat `vim.pack.update(nil, { offline = true })` as a way to
interactively explore currently installed plugins.
Problem: There are two fairly common workflows that involve lockfile and
can be made more straightforward in `vim.pack`:
1. Revert latest update. Like if it introduced unwanted behavior.
2. Update to a revision in the lockfile. Like if already updated
on another machine, verified that everything works, `git add` +
`git commit` + `git push` the config, and want to have the same
plugin states on current machine.
Solution: Make `update` allow `opts.target`. By default it uses
`version` from a plugin specification (like a regular "get new changes
from source" workflow). But it also allows `"lockfile"` value to
indicate that target revision after update should be taken from the
current lockfile verbatim.
With this, the workflows are:
1. Revert (somehow) to the lockfile before the update, restart, and
`vim.pack.update({ 'plugin' }, { target = 'lockfile' })`. If Git
tracked, revert with `git checkout HEAD -- nvim-pack-lock.json`.
For non-VCS tracked lockfile, the revisions can be taken from the
log file. It would be nicer if `update()` would backup a lockfile
before doing an update, but that might require discussions.
2. `git pull` + `:restart` +
`vim.pack.update(nil, { target = 'lockfile' })`.
The only caveats are for new and deleted plugins:
- New plugins (not present locally but present in the lockfile)
will be installed at lockfile revision during restart.
- Deleted plugins (present locally but not present in the
lockfile) will still be present: both locally *and* in the
lockfile. They can be located by
`git diff -- nvim-pack-lock.json` and require manual
`vim.pack.del({ 'old-plugin1', 'old-plugin2' })`.
Problem:
`on_accept` is a bit cumbersome to customize.
Solution:
* Before: users had to override the entire `on_accept` logic for their changes to be applied.
* Now: users can modify the item and return it to apply the modified changes, or return `nil` to fully customize how the changes are applied.
Problem: Changing `src` of already installed plugin currently takes
effect immediately inside `vim.pack.add()` and acts as "delete and
later fresh install". Although more robust, this might lead to
unintentional data loss (since plugin is deleted) if the plugin was
manually modified or the new source is not valid.
Also this introduces unnecessary differentiation between "change
`version`" and "change `src`" of already installed plugin.
Solution: Require an explicit `vim.pack.update()` to change plugin's
source. It is done by conditionally changing `origin` remote of the
Git repo. The effect does not require update confirmation in order to
have new changes fetched from the new `src` right away.
If in the future there are more types of plugins supported (i.e. not
only Git repos), also do extra work (like delete + install) during
`vim.pack.update()`.
Problem: vim.keymap.del has 'modes' as it's first argument while vim.keymap.set
has 'mode' as it's first argument despite both 'mode' and 'modes' taking in the
same type input of String or String[].
Solution: Updated vim.keymap.set docs to refer to it's first argument
as 'modes'.
Problem:
- Despite [nvim-lspconfig](https://github.com/neovim/nvim-lspconfig)
claims to be a "data-only" plugin, in fact it still provides some
user-facing commands because they haven't been upstreamed to Nvim.
Solution:
- Upstream `:LspRestart`, `:LspStart` and `:LspStop` commands as `:lsp
restart`, `:lsp start` and `:lsp stop` respectively.
Co-authored-by: glepnir <glephunter@gmail.com>
Problem:
The builtin terminfo defs don't include xterm-ghostty, so features like
`kTerm_set_underline_style` are missing when building without unibilium.
Solution:
- Add ghostty to `gen_terminfo.lua`.
- Note: The ncurses defs are somewhat different than what ghostty ships.
- Special-case ghostty in `terminfo_from_builtin`.
- Add leading "$" to match other environment variable tags.
- Clarify :help $NoDefaultCurrentDirectoryInExePath.
closes: vim/vim#18895bfb9f5c40e
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Problem:
After bc0635a9fc `vim.wait()` rejects floats
and NaN values.
Solution:
Restore the prior behavior, while still supporting `math.huge`. Update
tests to cover float case.
Problem:
Current options for powershell and pwsh had mistakes and rationale
behind them was not clear.
Solution:
Update the suggested options by splitting up powershell and pwsh, as
well as ensuring that all options work and rationale is documented and
discussed.
Problem: When exiting at the end of the more prompt (at the hit enter
prompt) by hitting q the recording mode will be started.
(Jakub Łuczyński)
Solution: Don't add the q key to the typeahead buffer
in the function wait_return (Bjoern Foersterling)
fixes: vim/vim#2589closes: vim/vim#18889ecce3497fa
Co-authored-by: Bjoern Foersterling <bjoern.foersterling@gmail.com>
Problem: diff: missing diff size limit for xdiff
Solution: Impose file size limit for internal diff (xdiff)
(Yee Cheng Chin).
Git imposes a hard cap on file size for content that it passes to xdiff
(added to Git in dcd1742e56e, defined in xdiff-interface.h), due to
integer overflow concerns in xdiff. Vim doesn't specify such a limit
right now, which means it's possible for a user to diff a large file
(1GB+) and trigger these overflow issues.
Add the same size limit (1GB minus 1MB) to Vim and simply throws an
error when Vim encounters files larger than said limit. For now, reuse
the same error message regarding internal diff failures. There is no
need to add the same limit for external diff as it's up to each tool to
error check their input to decide what is appropriate or not.
closes: vim/vim#188914af6d9755c
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
Problem:
`clint.py` is the last python in our codebase, and beyond that it needs
some cleanup. And it lacks tests, so modifying it can be painful.
Also, we need a way to add ad-hoc lint rules for *Lua*, so it will help
to have our ad-hoc rules for C in the same language (the scripts may
share functions/techniques): https://github.com/neovim/neovim/issues/28372
Solution:
- convert to `clint.lua` (mostly AI-generated, but it now has test
coverage, unlike `clint.py`)
- drop rules that are no longer needed:
- "readability/multiline_string"
- technially still relevant, but very uncommon so doesn't really matter.
- "--line-length"
- Not used in the old clint.py, nor the new clint.lua.
- "comment whitespace" check
- It is enforced by uncrustify.
- "TODO" check
- The `-google-readability-function-size` clang-tidy rule enforces
"TODO(user)" format. (It was already enabled long ago.)
Problem: :stag does not use 'swichtbuf' option, though the
documentation states differently
(Christian Brabandt)
Solution: Respect 'switchbuf' option (Yegappan Lakshmanan).
related: vim/vim#18845closes: vim/vim#18856efc7509be2
Cherry-pick some test_tagjump.vim changes from patches 9.0.{0363,0767}.
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem:
Our LSP type system didnt have a concept of RegistrationMethods, this is where the method to dynamically register for a capability is sent to a different method endpoint then is used to call it. Eg `textDocument/semanticTokens` rather than the specific full/range/delta methods
Solution:
Extended generator to create `vim.lsp.protocol.Methods.Registration` with these registration methods. Also extend `_request_name_to_client_capability` to cover these methods. Adjust typing to suit
