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>
The ui_rgb_attached function determines if any UI is attached which
supports RGB (truecolor). We determine if the TUI supports RGB via the
'termguicolors' option which is checked at the beginning of this
function. If the TUI does not support RGB ('termguicolors' is unset), we
check to see if any _other_ UI is attached which supports RGB.
Normally, the TUI's "rgb" flag and the 'termguicolors' option are the
same. However, they may differ during startup when the "rgb" flag is set
by tui/tui.c to indicate to the core that the terminal emulator supports
truecolor. The 'termguicolors' option is not actually set until
_defaults.lua runs.
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>
Problem: block_editing errors out when using <enter>
(Ali Rizvi-Santiago, after v9.1.0274)
Solution: Change ins_len from size_t to int so that the test
if ins_len is negative actually works properly
Add a test, so that this doesn't regress.
fixes: vim/vim#149601fb9eae579
Co-authored-by: Christian Brabandt <cb@256bit.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.
The latter was mostly relevant with the past char_u madness.
NOTE: STRCAT also functioned as a counterfeit "NOLINT" for clint
apparently. But NOLINT-ing every usecase is just the same as disabling
the check entirely.
Problem: Legacy :sign API still allows placing signs beyond the end of
the buffer. This is unaccounted for by the signcolumn tracking
logic and is disallowed in general for the extmark API which
implements it now.
Solution: Clamp legacy sign line number to the length of the buffer.
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>
`nvim_get_option_value` throws a warning if both `scope` and `buf`
options are used at the same time. This is because using `buf` always
implies `scope` is local, and is therefore not needed. There's however
no need to error if `scope` is already set "local" as it's the correct
value.
Problem: Inconsistencies between functions for option flags.
Solution: Consistently use "unsigned int" as return type and rename
get_bkc_value() to get_bkc_flags() (zeertzjq).
closes: vim/vim#14925aa925eeb97
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>
If you like it you shouldn't put a ring on it.
This is what _every_ consumer of RStream used anyway, either by calling
rbuffer_reset, or rbuffer_consumed_compact (same as rbuffer_reset
without needing a scratch buffer), or by consuming everything in
each stream_read_cb call directly.
