There can be other places that access window buffer info (e.g.
`tabpagebuflist()`), so checking `w_closing` in `win_findbuf()` doesn't
solve the crash in all cases, and may also cause Nvim's behavior to
diverge from Vim.
Fix#14998
Command preview now behaves like inccommand=nosplit when there's not
enough room for the preview window to be opened instead of aborting,
which is consistent with old behavior of 'inccommand'.
Many filetypes from filetype.vim set buffer-local variables, meaning
vim.filetype.match cannot be used without side effects. Instead of
setting these buffer-local variables in the filetype detection functions
themselves, have vim.filetype.match return an optional function value
that, when called, sets these variables. This allows vim.filetype.match
to work without side effects.
The "first run" has high variability. Looks like the test failures
correlate with 545dc82c1b
, which makes sense because that improves "first run" performance.
So the `1000*` factor of this test could be adjusted to e.g. `300*` or `500*`.
ref https://github.com/neovim/neovim/pull/16945
* on_scrollback_option_changed renamed to adjust_scrollback. The
function name did not correspond to what it was doing. It is
called unconditionally in every refresh of the terminal
unrelated if the scrollback option was changed.
* new on_scrollback_option_changed function, which calls
refresh_terminal, which then calls adjust_scrollback
* terminal_check_size is not the appropriate function to call when the
option is changed since it only conditionally adjusts the scrollback.
Use the new on_scrollback_option_changed
fixes#15477fixes#11811
Most LSP servers require the notification to correctly load the
settings and for those who don't it doesn't cause any harm.
So far this is done in lspconfig, but with the addition of vim.lsp.start
it should be part of core.
clang: Result of operation is garbage or undefined
clang: Uninitialized argument value
Also check for == 's' instead of != 'n' as it is more straightforward.
Also fix another unrelated PVS warning:
PVS/V1071: Return value of win_comp_pos() is not always used
Problem:
https://github.com/neovim/neovim/pull/18720#issuecomment-1142614996
The vim.health module is detected as a healthcheck, which produces spurious errors:
vim: require("vim.health").check()
========================================================================
- ERROR: Failed to run healthcheck for "vim" plugin. Exception:
function health#check, line 20
Vim(eval):E5108: Error executing lua [string "luaeval()"]:1: attempt to call field 'check' (a nil value)
stack traceback:
[string "luaeval()"]:1: in main chunk
Solution:
Skip vim.health when discovering healthchecks.
Also avoid referring to mappings as "keymaps" in commands and docs.
*map_empty_rhs* *map-empty-rhs*
You can create an empty {rhs} by typing nothing after a single CTRL-V (you
have to type CTRL-V two times). Unfortunately, you cannot do this in a vimrc
file.
- Complete function:
There was lots of unnecessary C code for the complete function, therefore
moving it to Lua and use all the plumbing we have in place to retrieve the
results.
- Moving the module:
It's important we keep nvim lua modules name spaced, avoids conflict with
plugins, luarocks, etc.
Problem:
1. The main log routine does not protect itself against recursion.
log_lock() doesn't guard against recursion, it would deadlock...
2. 22b52dd462 (#11501) regressed 6f27f5ef91 (#10172), because
set_init_1..process_spawn tries to log (see backtrace below), but the
mutex isn't initialized yet. Even if the mutex were valid, we don't
want early logging to fallback to stderr because that can break
embedders when stdio is used for RPC.
frame 1: 0x00000001001d54f4 nvim`open_log_file at log.c:205:7
frame 2: 0x00000001001d5390 nvim`logmsg(log_level=1, context="UI: ", func_name=0x0000000000000000, line_num=-1, eol=true, fmt="win_viewport") at log.c:150:20
frame : 0x000000010039aea2 nvim`ui_call_win_viewport(grid=2, win=1000, topline=0, botline=1, curline=0, curcol=0, line_count=1) at ui_events_call.generated.h:321:3
frame 4: 0x00000001003dfefc nvim`ui_ext_win_viewport(wp=0x0000000101816400) at window.c:939:5
frame 5: 0x00000001003ec5b4 nvim`win_ui_flush at window.c:7303:7
frame 6: 0x00000001003a04c0 nvim`ui_flush at ui.c:508:3
frame 7: 0x00000001002966ba nvim`do_os_system(argv=0x0000600000c0c000, input=0x0000000000000000, len=0, output=0x0000000000000000, nread=0x00007ff7bfefe830, silent=false, forward_output=false) at shell.c:894:3
frame 8: 0x0000000100295f68 nvim`os_call_shell(cmd="unset nonomatch; vimglob() { while [ $# -ge 1 ]; do echo \"$1\"; shift; done }; vimglob >/var/folders/gk/3tttv_md06987tlwpyp62jrw0000gn/T/nvimwwvwfD/0 ~foo", opts=kShellOptExpand | kShellOptSilent | kShellOptHideMess, extra_args=0x0000000000000000) at shell.c:663:18
frame 9: 0x0000000100295845 nvim`call_shell(cmd="unset nonomatch; vimglob() { while [ $# -ge 1 ]; do echo \"$1\"; shift; done }; vimglob >/var/folders/gk/3tttv_md06987tlwpyp62jrw0000gn/T/nvimwwvwfD/0 ~foo", opts=kShellOptExpand | kShellOptSilent | kShellOptHideMess, extra_shell_arg=0x0000000000000000) at shell.c:712:14
frame 10: 0x0000000100294c6f nvim`os_expand_wildcards(num_pat=1, pat=0x00007ff7bfefeb20, num_file=0x00007ff7bfefee58, file=0x00007ff7bfefee60, flags=43) at shell.c:328:7
...
frame 23: 0x000000010028ccef nvim`expand_env_esc(srcp=",~foo", dst="~foo", dstlen=4094, esc=false, one=false, prefix=0x0000000000000000) at env.c:673:17
frame 24: 0x000000010026fdd5 nvim`option_expand(opt_idx=29, val=",~foo") at option.c:1950:3
frame 25: 0x000000010026f129 nvim`set_init_1(clean_arg=false) at option.c:558:19
frame 26: 0x00000001001ea25e nvim`early_init(paramp=0x00007ff7bfeff5f0) at main.c:198:3
frame 27: 0x00000001001ea6bf nvim`main(argc=1, argv=0x00007ff7bfeff848) at main.c:255:3
Solution:
1. Check for recursion, show "internal error" message.
- FUTURE: when "remote TUI" is merged, can we remove log_lock()?
2. Skip logging if log_init wasn't called yet.
Adds an `smods` key to `nvim_create_user_command` Lua command callbacks,
which has command modifiers but in a structured format. This removes the
need to manually parse command modifiers. It also reduces friction in
using `nvim_cmd` inside a Lua command callback.
The async nature of feed_command caused a race condition on the calls
to delete, leaving the files on the root of the repo. Just use os.remove
and no need to wipeout.
Previously, there was a bug where setting the local value of 'winbar' to
itself would cause winbar to appear on a floating window, which is
undesirable. This fix makes it so that it's explicitly required for the
window-local value of 'winbar' for a floating window to be set in order
for winbar to be shown on that window.
Neovim already removed `evim` (or any similar flags). The 'insertmode'
option is a weird remnant, so get rid of it.
The 'insertmode' option is replaced with a script that closely emulates
the option. This script is documented at :help 'insertmode'
Problem:
If there are floating windows when `:mksession` runs, the session cannot
be properly restored.
Solution:
Change `:mksession` to skip floating windows. This matches Vim's
treatment of popup windows.
An alternative approach could have `:mksession` save floating windows
that can be _properly_ restored (rather than skip them entirely, which
is what this PR does). While that would seemingly be a more complete
fix, that could present additional issues since floating windows are
ordinarily created by plugins, and they may no longer be properly under
a plugin's control when restored.
closes#18432
from ~30 to ~20 secs with ASAN build
- feedkeys test: the same substitute was repeated, and not even correctly spelled
- don't clear() in a tight loop. "bwipe!" is enough to erase undo history
- error in cnoremap mapping causes a check_for_delay(). <c-c> it away.
Cuts down typical run time for `plugin/lsp_spec.lua`
from 70 secs to 12 secs in ASAN CI build.
This happens in ASAN/EXIT_FREE builds where nvim waits 2000ms due to
unclosed handled. I wasn't able to pin-point the exact cause.
But these tests ran in nested context where two server/client pairs
were setup for no good reason. Moving these tests out so only one client
is being setup fixed the exit hang.
fs_init() must be called before early_init() in init/helpers.lua
If I run 'make unittest' on my Mac (macOS 10.14/Mojave or 12/Big Sur, intel
CPU), every test produce a core dump.
Call sequence in the core is:
early_init() main.c:197
set_init_1() option.c:508
runtimepath_default() runtime.c:1205
get_lib_dir() runtime.c:1175
os_isdir() fs.c:137
os_getperm() fs.c:777
os_stat() fs.c:761
fs_loop_lock() fs.c:72
uv_mutex_lock(&fs_loop_mutex) thread.c:352
abort()
.deps/build/src/libuv/src/unix/thread.c:
void uv_mutex_lock(uv_mutex_t* mutex) {
if (pthread_mutex_lock(mutex))
abort(); // line 352
}
So pthread_mutex_lock(&fs_loop_mutex) failed. The reason seems to be simple.
fs_init() was not called and fs_loop_mutex has not been initialized. fs_init()
was moved out from early_init() in main.c by
b87867e69e, but unit/helpers.lua was not updated
accordingly.
The current approach of using `on_attach` callbacks for configuring
buffers for LSP is suboptimal:
1. It does not use the standard Nvim interface for driving and hooking
into events (i.e. autocommands)
2. There is no way for "third parties" (e.g. plugins) to hook into the
event. This means that *all* buffer configuration must go into the
user-supplied on_attach callback. This also makes it impossible for
these configurations to be modular, since it all must happen in the
same place.
3. There is currently no way to do something when a client detaches from
a buffer (there is no `on_detach` callback).
The solution is to use the traditional method of event handling in Nvim:
autocommands. When a LSP client is attached to a buffer, fire a
`LspAttach`. Likewise, when a client detaches from a buffer fire a
`LspDetach` event.
This enables plugins to easily add LSP-specific configuration to buffers
as well as enabling users to make their own configurations more modular
(e.g. by creating multiple LspAttach autocommands that each do
something unique).
Remove the command('qall!') from mksession_spec.lua because it prevents
helpers.rmdir() from retrying.
Allow extra trailing spaces when matching terminal lines.
Problem:
q in "$MANPAGER mode" does not quit Nvim. This is because
ftplugin/man.vim creates its own mapping:
nnoremap <silent> <buffer> <nowait> q :lclose<CR><C-W>c
which overrides the one set by the autoload file when using :Man!
("$MANPAGER mode")
Solution:
Set b:pager during "$MANPAGER mode" so that ftplugin/man.vim can set the
mapping correctly.
Fixes#18281
Ref #17791
Helped-by: Gregory Anders <8965202+gpanders@users.noreply.github.com>
Implement filtering of actions based on the kind when passing the 'only'
parameter to code_action(). Action kinds are hierachical with a '.' as
the separator, and the filter thus allows, for example, both 'quickfix'
and 'quickfix.foo' when requestiong only 'quickfix'.
Fix https://github.com/neovim/neovim/pull/18221#issuecomment-1110179121
`:tabmove` takes either an argument (`:tabmove -`) or an address (`:-tabmove`).
The code assumed that `:tabmove` is the first command on the cmdline, but that
is not the case when using additional modifiers like `:silent`.
Make the addr parsing more robust by searching the command first, then going
back to check for a potential address `-`.
Most code in keymap.h is for keycode definitions, while most code in
keymap.c is for the parsing and conversion of keycodes.
The name "keymap" may also make people think these two files are for
mappings, while in fact keycodes are used even when no mappings are
involved, so "keycodes" should be a better file name than "keymap".
Adds the API function `nvim_cmd` which allows executing an Ex-command through a Dictionary which can have the same values as the return value of `nvim_parse_cmd()`. This makes it much easier to do things like passing arguments with a space to commands that otherwise may not allow it, or to make commands interpret certain characters literally when they otherwise would not.
It seems range and count can be used together in commands. This PR fixes
the behavior of `nvim_parse_cmd` for those cases by removing the mutual
exclusivity of "range" and "count". It also removes range line number
validation for `nvim_parse_cmd` as it's not its job to validate the
command.
Adds filter and id options to filter the client to use for rename.
Similar to the recently added `format` function.
rename will use all matching clients one after another and can handle a
mix of prepareRename/rename support. Also ensures the right
`offset_encoding` is used for the `make_position_params` calls
This fixes issues where subsequent calls to vim.lsp.codelens.refresh()
would have no effect due to the buffer not getting cleared from the
active_refresh table.
Examples of how such scenarios would occur are:
- A textDocument/codeLens result yielded an error.
- The 'textDocument/codeLens' handler was overriden in such a way that
it no longer called vim.lsp.codelens.on_codelens().
Changes the `range` value in `nvim_parse_cmd` into an array to describe
range information more concisely. Also makes `range` and `count` be
mutually exclusive by making count `-1` when command takes a range
instead of a count. Additionally corrects the behavior of `count` for
built-in commands by making the default count `0`.
Adds range, count and reg to the return values of nvim_parse_cmd. Also makes
line1 and line2 be -1 if the command does not take a range. Also moves
nvim_parse_cmd to vimscript.c because it fits better there.
PROBLEM
------------------------------------------------------------------------
$NVIM_LISTEN_ADDRESS has conflicting purposes as both a parameter ("the
current process should listen on this address") and a descriptor ("the
current process is a child of this address").
This contradiction means the presence of NVIM_LISTEN_ADDRESS is
ambiguous, so child Nvim always tries to listen on its _parent's_
socket. This is the cause of lots of "Failed to start server" spam in
our test/CI logs:
WARN 2022-04-30… server_start:154: Failed to start server: address already in use: \\.\pipe\nvim-4480-0
WARN 2022-04-30… server_start:154: Failed to start server: address already in use: \\.\pipe\nvim-2168-0
SOLUTION
------------------------------------------------------------------------
1. Set $NVIM to the parent v:servername, *only* in child processes.
- Now the correct way to detect a "parent" Nvim is to check for $NVIM.
2. Do NOT set $NVIM_LISTEN_ADDRESS in child processes.
3. On startup if $NVIM_LISTEN_ADDRESS exists, unset it immediately after
server init.
4. Open a channel to parent automatically, expose it as v:parent.
Fixes#3118Fixes#6764Fixes#9336
Ref https://github.com/neovim/neovim/pull/8247#issuecomment-380275696
Ref #8696
Deprecates the existing `vim.lsp.buf.formatting` function.
With this, `vim.lsp.buf.format` will replace all three:
- vim.lsp.buf.formatting
- vim.lsp.buf.formatting_sync
- vim.lsp.buf.formatting_seq_sync
* feat(lsp)!: remove capabilities sanitization
Users must now access client.server_capabilities which matches the same
structure as the protocol.
https://microsoft.github.io/language-server-protocol/specification
client.resolved_capabilities is no longer used to gate capabilities, and
will be removed in a future release.
BREAKING CHANGE
Co-authored-by: Mathias Fussenegger <f.mathias@zignar.net>
Implement two new options to vim.lsp.buf.code_action():
- filter (function): predicate taking an Action as input, and returning
a boolean.
- apply (boolean): when set to true, and there is just one remaining
action (after filtering), the action is applied without user query.
These options can, for example, be used to filter out, and automatically
apply, the action indicated by the server to be preferred:
vim.lsp.buf.code_action({
filter = function(action)
return action.isPreferred
end,
apply = true,
})
Fix#17514.
Problem: Modifiers not simplified when timed out or using feedkeys() with
'n" flag.
Solution: Adjust how mapped flag and timeout are used. (closesvim/vim#10305)
68a573ce2b
Problem: When there is a partially matching map and modifyOtherKeys is
active a full map may not work.
Solution: Only simplify modifiers when there is no matching mapping.
(closesvim/vim#8792)
196c3850db
Omit test as it sends terminal codes. Use a Lua test instead.
Problem: CTRL-R CTRL-R doesn't work with modifyOtherKeys.
Solution: Allow key codes when fetching argument for CTRL-R. (closesvim/vim#5266)
Also fix CTRL-G in Insert mode.
38571a04b4
Omit test as it sends terminal codes. Use a Lua test instead.
Problem: Mapping with partly modifyOtherKeys code does not work.
Solution: If there is no mapping with a separate modifier include the
modifier in the key and then try mapping again. (closesvim/vim#6200)
975a880a13
Cherry-pick applicable part of put_string_in_typebuf().
Revert related changes from 10a5825.
Use KEYLEN_PART_KEY for incomplete modifier sequence.
Omit test as it sends terminal codes. Use a Lua test instead.
