Problem:
Remote UIs can't execute lua code when a blocking prompt is waiting for
input. This is needed when implementing IME pre-edit for example.
Solution:
Add an `nvim__exec_lua_fast` experimental API function, which is allowed
to run instead of being queued until after the message has been shown.
Problem:
LSP server may not exit even after the client was stopped/disabled via enable(false).
Solution:
Automatically force-stop after a timeout, unless `client.flags.exit_timeout = false`.
Problem: Null pointer dereference when checking *wp->w_p_stl.
win_set_inner_size called twice in win_new_float.
Solution: Add null check for wp->w_p_stl. Remove redundant
win_set_inner_size call as win_config_float already calls it.
Problem: completion: complete_match() Vim script function and
'isexpand' option are not that useful and confusing
(after v9.1.1341)
Solution: Remove function and option and clean up code and documentation
(Girish Palya).
complete_match() and 'isexpand' add no real functionality to Vim. They
duplicate what `strridx()` already does, yet pretend to be part of the
completion system. They have nothing to do with the completion mechanism.
* `f_complete_match()` in `insexpand.c` does not call any completion code.
It’s just a `STRNCMP()` wrapper with fluff logic.
* `'isexpand'` exists only as a proxy argument to that function.
It does nothing on its own and amounts to misuse of a new option.
The following Vim script function can be used to implement the same
functionality:
```vim
func CompleteMatch(triggers, sep=',')
let line = getline('.')->strpart(0, col('.') - 1)
let result = []
for trig in split(a:triggers, a:sep)
let idx = strridx(line, trig)
if l:idx >= 0
call add(result, [idx + 1, trig])
endif
endfor
return result
endfunc
```
related: vim/vim#16716fixes: vim/vim#18563closes: vim/vim#18790cbcbff8712
Co-authored-by: Girish Palya <girishji@gmail.com>
Problem: completion: 'completefuzzycollect' option is too obscure
Solution: Deprecate the option, but don't error out for existing scripts,
behave like 'completefuzzycollect' is set when fuzzy
completion is enabled (Girish Palya).
fixes: vim/vim#18498closes: vim/vim#1878833fbfe003c
Remove this option completely, as it's introduced in Nvim v0.12 cycle.
Co-authored-by: Girish Palya <girishji@gmail.com>
- Change "Prepended" (past tense) to "Prepend" (present tense,
imperative).
- Add short examples clarifying the behavior of prepending a count to
commands that jump to changes in diff mode.
closes: vim/vim#18810712b650332
Co-authored-by: Brent Pappas <pappasbrent@gmail.com>
Problem:
nvim_get_commands does not return callbacks defined for
"preview", "complete", or the command itself.
Solution:
- Return Lua function as "callback" field in a Lua context.
- Return "preview" function in a Lua context.
- BREAKING: Return "complete" as a function instead of a boolean.
Problem:
`diagnostic.status()` is configured via `config.signs`, but users may
want diagnostics only in statusline, not in the gutter (signs).
Solution:
Add `config.status`.
Problem:
LSP incremental selection provides default visual-mode keymaps for `an`
and `in`. Operator-pending mode is not supported, so `dan` and `can` do
not apply the operation.
Solution:
Modify selection_range() to be synchronous.
Add operator-pending mappings.
Add "Environment variables are expanded |:set_env|" documentation to
options that have the P_EXPAND flag but were missing this note.
Updated options:
- 'cdpath'
- 'dictionary'
- 'mkspellmem'
- 'packpath'
- 'runtimepath'
- 'spellfile'
- 'spellsuggest'
- 'thesaurus'
- 'ttytype'
- 'undodir'
- 'verbosefile'
- 'viewdir'
- 'viminfofile'
These options support environment variable expansion in their values
(e.g., $HOME, $USER) but the documentation didn't explicitly mention
this capability. This brings their documentation in line with other
options like backupdir, directory, and makeprg that already include
this note.
closes: vim/vim#187912190036c8c
Co-authored-by: Alex Plate <AlexPl292@gmail.com>
Problem:
We have too many build flags.
BUNDLED_CMAKE_FLAG is redundant with DEPS_CMAKE_FLAGS.
Solution:
In documentation, refer to DEPS_CMAKE_FLAGS instead of BUNDLED_CMAKE_FLAG.
Technically the current behavior does match documentation. However, the
keys following <Cmd>/K_LUA aren't normally received by vim.on_key()
callbacks either, so it does makes sense to discard them along with the
preceding key.
One may also argue that vim.on_key() callbacks should instead receive
the following keys together with the <Cmd>/K_LUA, but doing that may
cause some performance problems, and even in that case the keys should
still be discarded together.
Problem: running ./build/bin/nvim without make install
- doesn't respect local changes in ./runtime,
- includes the path where Nvim would be installed,
- ignores changes in precompiled Lua modules (like .../vim/_editor.lua)
Solution:
- use VIMRUNTIME=./runtime,
- use --luamod-dev
Problem: the opts table also is param of util.open_floating_preview,
vim.diagnostic.Opts.Float missing some fields of open_floating_preview.
Solution: diagnostic.Opts.Float extend util.open_floating_preview.Opts
Fix#29267
Problem: No way to customize completion order across multiple servers.
Solution: Add `cmp` function to `vim.lsp.completion.enable()` options
for custom sorting logic.
Problem: Cannot reuse same config with noautocmd for both window
creation and updates, even when value is unchanged.
Solution: Only reject noautocmd changes for existing windows.
This reverts 2495e7e. That past change meant that we would modify the
buffer contents of a tmux session if it exists, even if the current Nvim
process wasn't running inside of it. Depending on the tmux
configuration, this could even affect the clipboard of an actually
attached tmux client, since tmux itself uses OSC 52 to forward buffer
writes to attached clients.
While autodetection is usually a trade-off and can rarely make everybody
happy, this behavior goes counter the principle of least surprise. If
really desired, it can be brought back by explicit configuration.
**Problem:** Whenever `LanguageTree:parse()` is called, injection trees
from previously parsed ranges are dropped.
**Solution:** Allow the function to accept a list of ranges, so it can
return injection trees for all the given ranges.
Co-authored-by: Jaehwang Jung <tomtomjhj@gmail.com>
Problem: `nvim://` scheme feels more like a generalized interface that
may be requested externally, and it acts like CLI args (roughly).
This is how `vscode://` works.
Anything that behaves like an "app" or a "protocol" deserves its own
scheme. For such Nvim-owned things they will be called `nvim-xx://`.
Solution: Use `nvim-pack://confirm#<bufnr>` template for confirmation
buffer name instead of `nvim://pack-confirm#<bufnr>`.
Problem: Lockfile can become out of sync with what is actually installed
on disk when user performs (somewhat reasonable) manual actions like:
- Delete lockfile and expect it to regenerate.
- Delete plugin directory without `vim.pack.del()`.
- Manually edit lock data in a bad way.
Solution: Synchronize lockfile data with installed plugins on every
lockfile read. In particular:
1. Install immediately all missing plugins with valid lock data.
This helps with "manually delete plugin directory" case by
prompting user to figure out how to properly delete a plugin.
2. Repair lock data for properly installed plugins.
This helps with "manually deleted lockfile", "manually edited
lockfile in an unexpected way", "installation terminated due to
timeout" cases.
3. Remove unrepairable corrupted lock data and their plugins. This
includes bad lock data for missing plugins and any lock data
for corrupted plugins (right now this only means that plugin
path is not a directory, but can be built upon).
Step 1 also improves usability in case there are lazy loaded plugins
that are rarely loaded (like on `FileType` event, for example):
- Previously starting with config+lockfile on a new machine only
installs rare `vim.pack.add()` plugin after it is called (while
an entry in lockfile would still be present). This could be
problematic if there is no Internet connection, for example.
- Now all plugins from the lockfile are installed before actually
executing the first `vim.pack.add()` call in 'init.lua'. And later
they are only loaded on a rare `vim.pack.add()` call.
---
Synchronizing lockfile on its every read makes it work more robustly
if other `vim.pack` functions are called without any `vim.pack.add()`.
---
Performance for a regular startup (good lockfile, everything is
installed) is not affected and usually even increased. The bottleneck
in this area is figuring out which plugins need to be installed.
Previously the check was done by `vim.uv.fs_stat()` for every plugin
in `vim.pack.add()`. Now it is replaced with a single `vim.fs.dir()`
traversal during lockfile sync while later using lockfile data to
figure out if plugin needs to be installed.
The single `vim.fs.dir` approach scales better than `vim.uv.fs_stat`,
but might be less performant if there are many plugins that will be
not loaded via `vim.pack.add()` during startup.
Rough estimate of how long the same steps (read lockfile and normalize
plugin array) take with a single `vim.pack.add()` filled with 43
plugins benchmarking:
- Before commit: ~700 ms
- After commit: ~550 ms
Problem: Currently it is possible to have plugin in a "partial install"
state when `git clone` was successfull but `git checkout` was not.
This was done to not checkout default branch by default in these
situations (for security reasons).
The problem is that it adds complexity when both dealing with lockfile
(plugin's `rev` might be `nil`) and in how `src` and `version` are
treated (wrong `src` - no plugin on disk; wrong `version` - "partial"
plugin on disk).
Solution: Treat plugin as "installed" if both `git clone` and
`git checkout` are successful, while ensuring that not installed
plugins are not on disk and in lockfile.
This also means that if in 'init.lua' there is a `vim.pack.add()` with
bad `version`, for first install there will be an informative error
about it BUT next session will also try to install it. The solution is
the same - adjust `version` beforehand.
Problem: No example workflow of how to revert after a bad update.
Solution: Add example workflow of how to revert after a bad update.
In future this might be improved by utilizing other `vim.pack`
features or via a dedicated function (like `vim.pack.restore()` that
restores all installed plugins to a state from the lockfile).
Problem: Changing `src` of an existing plugin cleanly requires manual
`vim.pack.del()` prior to executing `vim.pack.add()` with a new `src`.
Solution: Autodetect `src` change for an existing plugin (by comparing
against lockfile data). If different - properly delete immediately and
treat this as new plugin installation.
Alternative solution might be to update `origin` remote in the
installed plugin after calling `vim.pack.update()`. Although, doable,
this 1) requires more code; and 2) works only for Git plugins (which
might be not the only type of plugins in the future). Automatic
"delete and clean install" feels more robust.
Problem: Plain `vim.pack.add()` calls (with default `opts.load`) does
not fully work if called inside 'plugin/' runtime directory. In
particular, 'plugin/' files of newly added plugins are not sourced.
This is because `opts.load` is `false` during the whole startup, which
means `:packadd!` is used (modify 'runtimepath' but not force source
newly added 'plugin/' files).
This use case is common due to users organizing their config as
separate files in '~/.config/nvim/plugin/'.
Solution: Use newly added `v:vim_did_init` to decide default `opts.load`
value instead of `v:vim_did_enter`.
Problem: Current requirement is Git>=2.36 as `--also-filter-submodules`
flag for `git clone` was introduced there. This is problematic since
default Git version on Ubuntu 22.04 is 2.34.
Solution: Relax minimal Git version to be (at least) 2.0 by selectively
applying necessary flags based on the current Git version.
As 2.0.0 was released in 2014-05-28 (almost the same age as Neovim
project itself), it is reasonable to drop any mention and checks on
minimal version altogether.
Problem:
Nvim does not recognize URI scheme with numeric characters. While rare, there
are URIs that contain numbers (e.g. [ed2k://](https://en.wikipedia.org/wiki/Ed2k_URI_scheme))
and characters like `+` (e.g. `svn+ssh`). I use it in
[distant.nvim](https://github.com/chipsenkbeil/distant.nvim) to support
multiple, distinct connections using `distant+1234://` as the scheme.
Otherwise, if you open a file with the same name & path on two different
machines from the same Nvim instance, their buffer names will conflict
when just using `distant://`.
Solution:
Adds full support for detecting URI scheme per
[RFC3986](https://www.rfc-editor.org/rfc/rfc3986#section-3.1)
Quote the special buffer names for consistency (see :help bufname()) and
so that they're not incorrectly highlighted as optional command
arguments.
closes: vim/vim#187309ab6a22c90
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Problem: confusing that there is the tag `undo-tree` (the Vim
implementation) and `undotree` (the Lua plugin for visualization).
Solution: rename tag to undotree-plugin. Mention the plugin in the docs of
|undotree|.
Problem:
- Exposing the raw config as table is a pattern not seen anywhere else
in the Nvim codebase.
- Old spellfile.vim docs still available, no new documentation
Solution:
- Exposing a `config()` function that both acts as "getter" and "setter"
is a much more common idiom (e.g. vim.lsp, vim.diagnostic).
- Add new documentation and link old docs to |spellfile.lua| instead of
|spellfile.vim|.
- :retab! line 1 and line 4 (main page heading).
- Use four columns whitespace before "by [Author]" in the user manual
heading to match the reference manual formatting.
- double space headings.
closes: vim/vim#18648542746521f
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
