Problem: completion text is highlighted even with no pattern found
Solution: use ins_compl_leader_len() instead of checking
compl_leader.length (glepnir)
closes: vim/vim#164229fddb8ae77
Co-authored-by: glepnir <glephunter@gmail.com>
Improve how to find the justify package
closes: vim/vim#164209598a6369b
Co-authored-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Peter Benjamin <petermbenjamin@gmail.com>
BREAKING CHANGE: This changes the list of diagnostics that are passed to
a diagnostic handler. If a handler is already filtering by severity
itself then this won't break anything, since the handler's filtering
will become a no-op. But handlers which depend on receiving the full
list of diagnostics may break.
Note that diagnostics are only filtered if the handler's configuration
has the `severity` option set. If `severity` is not set, the handler
still receives the full list of diagnostics.
Problem: ComplMatchIns highlight hard to read on light background
(after v9.1.0996)
Solution: define the highlighting group cleared, it should be configured in
colorschemes separately (glepnir)
closes: vim/vim#16414ad409876d9
Co-authored-by: glepnir <glephunter@gmail.com>
Match the '' escape sequence in literal strings. These were previously
ending the current string and starting another concatenated literal
string.
closes: vim/vim#16415695522dea3
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Problem: ComplMatchIns may highlight wrong text
Solution: don't highlight in case of fuzzy match,
skip-highlight when not inserting anything
(glepnir)
closes: vim/vim#16404e890887b80
Problem: Assert hit related to message kind, which is reset after a
ext_messages UI is forcibly detached, so the assertion is
expectedly false. Assert hit related to message grid variables
after an ext_messages UI attaches while message grid is scrolled.
Solution: Don't check message kind assertion if no ext_messages UI is
attached. Flush message grid when first/last ext_messages UI
attaches/detaches.
Problem:
The `nvim_notify` API (note: unrelated to `vim.notify()` Lua API) was
not given any real motivation in https://github.com/neovim/neovim/pull/13843
There are, and were, idiomatic and ergonomic alternatives already.
Solution:
Deprecate `nvim_notify`.
Problem: tests: ruby tests fail with Ruby 3.4
Solution: adjust expected output for Ruby 3.4
(Yee Cheng Chin)
Vim's Ruby tests relied on explicit matching of output texts which are
fragile in design. Ruby 3.4 has changed the output slightly (using
'name' instead of `name', and also using more spaces in dictionary
printouts). Modify the Vim tests to be less fragile to such changes.
closes: vim/vim#16411ebea31e454
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
Problem: leaking finished exception
(after v9.1.0984)
Solution: use finish_exception to clean up caught exceptions
(Yee Cheng Chin)
In Vimscript, v:exception/throwpoint/stacktrace are supposed to reflect
the currently caught exception, and be popped after the exception is
finished (via endtry, finally, or a thrown exception inside catch).
Vim9script does not handle this properly, and leaks them instead. This
is clearly visible when launching GVim with menu enabled. A caught
exception inside the s:BMShow() in menu.vim would show up when querying
`v:stacktrace` even though the exception was already caught and handled.
To fix this, just use the same functionality as Vimscript by calling
`finish_exception` to properly restore the states. Note that this
assumes `current_exception` is always the same as `caught_stack` which
believe should be the case.
Added tests for this. Also fix up test_stacktrace to properly test the
stack restore behavior where we have nested exceptions in catch blocks
and to also test the vim9script functionality properly.
- Also, remove its dependency on explicitly checking a line number in
runtest.vim which is a very fragile way to write tests as any minor
change in runtest.vim (shared among all tests) would require changing
test_stacktrace.vim. We don't actually need such granularity in the
test.
closes: vim/vim#164132051af1642
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
Problem:
Deprecated API `nvim_get_option()` doesn't validate the option name,
which leads to an assertion failure.
Solution:
Validate option name in `nvim_get_option()`.
Ref: #31894
Problem: We want to deprecate `nvim_err_write(ln)()` but there is no
obvious replacement (from Lua). Meanwhile we already have
`nvim_echo()` with an `opts` argument.
Solution: Add `err` argument to `nvim_echo()` that directly maps to
`:echoerr`.
If a "on_lines" callback changes the structure of the marktree, the
iterator (which is used for an entire window viewport) might now
point to invalid memory. Restore the iterator to the beginning of the
line in this case.
fixes#29484
Problem: filetype: TI assembly files are not recognized
Solution: inspect '*.sa' and assembly files and detect TI assembly
files, include filetype plugin and syntax script for TI
assembly files (Wu, Zhenyu)
closes: vim/vim#158274f73c07abf
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
Problem: too many strlen() calls in drawscreen.c
Solution: refactor drawscreen.c and remove calls to strlen(),
make get_keymap_str() (in screen.c) return string length
instead of TRUE/FALSE (John Marriott).
a21240b97d
Co-authored-by: John Marriott <basilisk@internode.on.net>
Problem: too many strlen() calls in insexpand.c
Solution: Refactor insexpand.c and reduce number of calls to STRLEN(),
fix a warning get_next_filename_completion(), add new function
ins_compl_leader_len() (John Marriott)
closes: vim/vim#160955e6ea92b2c
Co-authored-by: John Marriott <basilisk@internode.on.net>
Always match ex-bang explicitly rather than incidentally as the ! operator.
fixes: vim/vim#16221closes: vim/vim#164101718e7d07e
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Problem: incorrect return type doc causes luals `Annotations specify that at most 0 return value(s) are required, found 1 returned here instead.` diagnosis
Solution: correct return type doc
Problem: filetype: shaderslang files are not detected
Solution: detect '*.slang' files as shaderslang filetype,
include a filetype and syntax script (mtvare6)
Reference:
https://shader-slang.com/closes: vim/vim#16387616219f684
Co-authored-by: mtvare6 <mtvare6@proton.me>
Problem: Linking `TablineSel` to `Normal` makes it more noticeable with
`notermguicolors` but less so with `termguicolors` (compared to using
bold text in both cases).
Solution: use bold text with `termguicolors` and regular with
`notermguicolors`.
**Problem:** The treesitter `foldexpr` calls `get_parser()` for each
line in the buffer when calculating folds. This can be incredibly slow
for buffers where a parser cannot be found (because the result is not
cached), and exponentially more so when the user has many
`runtimepath`s.
**Solution:** Only fetch the parser when it is needed; that is, only
when initializing fold data for a buffer.
Co-authored-by: Jongwook Choi <wookayin@gmail.com>
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Problem: v:stacktrace has wrong type in Vim9 script.
Solution: Change the type to t_list_dict_any. Fix grammar in docs.
(zeertzjq)
closes: vim/vim#163906655bef330
Problem: Although patch 9.1.0990 fixed a real problem/inconsistency,
it also introduced new behavior that may break BWC and/or be
unexpected. Before 9.1.0990, window commands could make the
topframe smaller (without changing 'cmdheight'; quirk that is
now fixed), but did not allow extending the topframe beyond
the 'cmdheight' set by the user. After 9.1.0990, the user can
reduce the 'cmdheight' below the value they set explicitly,
through window commands, which may lead to confusion.
(aftere v9.1.0990)
Solution: Store the value explicitly set by the user and clamp the
'cmdheight' when resizing the topframe. This also applies to
dragging laststatus, which in contrast to window commands
_did_ allow reducing the 'cmdheight' to values below the one
set by the user. So with this patch there is still new
behavior, but I think in a way that is less surprising.
While at it, also fix a Coverity warning, introduced in
v9.1.0990 (Luuk van Baal)
c97e869535