Problem: Cannot see matched text in popup menu
Solution: Introduce 2 new highlighting groups: PmenuMatch and
PmenuMatchSel (glepnir)
closes: vim/vim#1469440c1c3317d
Co-authored-by: glepnir <glephunter@gmail.com>
Problem:
For snippets lsp.completion prefers the label if it is shorter than the
insertText or textEdit to support postfix completion cases but clangd
adds decoration characters to labels. E.g.: `•INT16_C(c)`
Solution:
Use parse_snippet on insertText/textEdit before checking if it is
shorter than the label.
Fixes https://github.com/neovim/neovim/issues/29301
Problem: both `StatusLineTerm`/`StatusLineTermNC` are now explicitly
used, but `:color vim` does not set them to the values used in Vim.
This might be fine if `:color vim` is treated as "the state of default
color scheme prior the big update", but it seems to be better treated
as "Vim's default color scheme" (how it is documented in its header).
Solution: add `StatusLineTerm`/`StatusLineTermNC` definitions to
'runtime/colors/vim.lua'.
Use explicit foreground colors ('Whte'/'Black') instead of `guifg=bg`
used in source, as the latter caused some problems in the past (if
`Normal` is not defined, `nvim_set_hl()` can't recognize `'bg'` as the
foreground value).
Also realign the rest of the background conditional highlight groups.
This reduces the number of nil checks around buf_versions usage
Test changes were lifted from 5c33815
Co-authored-by: Mathias Fussenegger <f.mathias@zignar.net>
this only changes the error message, so that it is clear that
the error is with the LSP server, rather than being a crash inside
nvim runtime scripts. We are already doing a lot of validation,
it's just that nil was being overlooked here.
This fixes issue #27395
Problem: termdebug plugin needs more love
Solution: start with some more Vim9 refactoring
to improve maintenance and readability
(Ubaldo Tiberi)
List of Changes and the Reasoning Behind Them:
1) Introduction of InitScriptVariables() Function:
Reasoning: This function has been introduced to ensure that when you open and
close Termdebug, and then open it again, there are no leftover script variable
values from the previous session. Leftover values could potentially cause
issues. The goal is for each Termdebug session to be independent of previous
sessions. At startup, all script variables are initialized. The only exception
is g:termdebug_loaded located at the very beginning of the script to prevent
sourcing the script twice. The variables are declared at script level and
defined in InitScriptVariables().
2) More Descriptive Variable Names:
Reasoning: The names of variables have been made more comprehensive. Almost
every Termdebug buffer now has a variable to indicate its name and another
variable to indicate its number, improving code readability and
maintainability. Due to the latest discussion around the &mousemodel option
save/restore mechanism, perhaps some other variables shall be prepended with
saved_.
3) Consistent Naming for GDB Terminal Buffers:
Reasoning: The name of the GDB terminal buffer now matches the name of the GDB
program being used, e.g., 'gdb', 'mygdb', 'arm-eabi-none-gdb', etc. This
ensures clarity and consistency in identifying buffers.
4) Other minor improvements:
Moved EchoErr() on top, added another test, some refactoring, mainly changed
several 0 and 1 to true and false
closes: vim/vim#14980ef8eab86e2
Co-authored-by: Ubaldo Tiberi <ubaldo.tiberi@volvo.com>
Make a formal definition for normal and single-element kinds
of annotations that otherwise require for their containment
to repeat each time all syntax groups that describe element
values.
Reference:
https://docs.oracle.com/javase/specs/jls/se21/html/jls-9.html#jls-9.7902b766858
Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
These highlight groups are used for the statusline in :terminal windows.
By default they link to StatusLine and StatusLineNC (respectively), so
there is no visual difference unless a colorscheme defines these groups
separately.
Problem: the previous documentation falsely states that "v" always
refers to the start of a visual area. In fact, the reference of "v" and
"." complement each other. If the cursor is at the start of
a (characterwise) visual area, then "v" refers to the end of the area.
Solution: be more verbose and explicit about the connection between "."
and "v" and also refer to |v_o| which many vim users will be familiar
with for visual areas.
210b39c2d6
Co-authored-by: Peter Aronoff <peter@aronoff.org>
Allow highlighting of strings within comments to be disabled by setting
g:vimsyn_comment_strings to false.
959c3c887b
Co-authored-by: dkearns <dougkearns@gmail.com>
When libvterm receives the OSC 52 escape sequence it ignores it because
Nvim does not set any selection callbacks. Install selection callbacks
that forward to the clipboard provider, so that setting the clipboard
with OSC 52 in the embedded terminal writes to the system clipboard
using the configured clipboard provider.
This change fixes an issue where glob patterns like `{a,ab}` would not
match `ab` because the first option `a` matches, then the end of the
string is expected but `b` is found, and LPeg does not backtrack to try
the next option `ab` which would match. The fix here is to also append
the rest of the pattern to the generated LPeg pattern for each option.
This changes a glob `{a,ab}` from being parsed as
("a" or "ab") "end of string"
to
("a" "end of string" or "ab" "end of string")
Here, matching against `ab` would try the first option, fail to match,
then proceed to the next option, and match.
The sacrifice this change makes is dropping support for nested `{}`
conditions, which VSCode doesn't seem to support or test AFAICT.
Fixes#28931
Co-authored-by: Sergey Slipchenko <faergeek@gmail.com>
It's a function to perform operations in their own sealed context,
similar to pythons `with`. This helps ease operations where you need to
perform an operation in a specific context, and then restore the
context.
Marked as private for now as it's not ready for public use. The current
plan is to start using this internally so we can discover and fix any
problems. Once this is ready to be exposed it will be renamed to
`vim.with`.
Usage:
```lua
local ret = vim._with({context = val}, function()
return "hello"
end)
```
, where `context` is any combination of:
- `buf`
- `emsg_silent`
- `hide`
- `horizontal`
- `keepalt`
- `keepjumps`
- `keepmarks`
- `keeppatterns`
- `lockmarks`
- `noautocmd`
- `options`
- `sandbox`
- `silent`
- `unsilent`
- `win`
(except for `win` and `buf` which can't be used at the same time). This
list will most likely be expanded in the future.
Work on https://github.com/neovim/neovim/issues/19832.
Co-authored-by: Lewis Russell <lewis6991@gmail.com>
Problem:
Text edits with the same position (both line and character) were being
reverse sorted prior to being applied which differs from the lsp spec
Solution:
Change the sort order for just the same position edits
* Revert "fix(lsp): account for changedtick version gap on modified reset (#29170)"
This reverts commit 2e6d295f79.
* Revert "refactor(lsp): replace util.buf_versions with changedtick (#28943)"
This reverts commit 5c33815448.
Allow whitespace between the :substitute command and its pattern
argument. Although unusual, it is supported and there are examples in
the wild.
Match Vi compatible :substitute commands like :s\/{string}/. See :help
E1270.
fixes: vim/vim#14920closes: vim/vim#1492392f4e91590
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Problem: Cannot have buffer-local value for 'completeopt'
(Nick Jensen).
Solution: Make 'completeopt' global-local (zeertzjq).
Also for some reason test Test_ColonEight_MultiByte seems to be failing
sporadically now. Let's mark it as flaky.
fixes: vim/vim#5487closes: vim/vim#14922529b9ad62a
We currently check $COLORTERM in the TUI process to determine if the
terminal supports 24 bit color (truecolor). If $COLORTERM is "truecolor"
or "24bit" then we automatically assume that the terminal supports
truecolor, but if $COLORTERM is set to any other value we still query
the terminal.
The `rgb` flag of the UI struct is a boolean which only indicates
whether the UI supports truecolor, but does not have a 3rd state that we
can use to represent "we don't know if the UI supports truecolor". We
currently use `rgb=false` to represent this "we don't know" state, and
we use XTGETTCAP and DECRQSS queries to determine at runtime if the
terminal supports truecolor. However, if $COLORTERM is set to a value
besides "truecolor" or "24bit" (e.g. "256" or "16) that is a clear
indication that the terminal _does not_ support truecolor, so it is
incorrect to treat `rgb=false` as "we don't know" in that case.
Instead, in the TUI process we only check for the terminfo capabilities.
This must be done in the TUI process because we do not have access to
this information in the core Neovim process when `_defaults.lua` runs.
If the TUI cannot determine truecolor support from terminfo alone, we
set `rgb=false` to indicate "we don't know if the terminal supports
truecolor yet, keep checking". When we get to `_defaults.lua`, we can
then check $COLORTERM and only query the terminal if it is unset.
This means that users can explicitly opt out of truecolor determination
by setting `COLORTERM=256` (or similar) in their environment.
