Refactor our implementation of querying for Kitty keyboard protocol
support:
- Remove usage of the "extkeys" term. This is not standard or really
used elsewhere. Use "key encoding" instead
- Replace usages of "CSIu" with "Kitty". "Kitty keyboard protocol" is
vastly more common than "CSIu" now
- Replace the countdown response counter with a simple boolean flag. We
don't actually need a countdown counter because we request the primary
device attributes along with the Kitty keyboard query, so we will
always receive a "terminating event", making a countdown/timer
unnecessary
- Move the CSI response handling into a dedicated function
- Bypass Unibilium for sending key encoding escape sequences. These
sequences are not part of terminfo and do not have any parameters, so
there's no reason to go through Unibilium
Problem: The legacy signlist data structures and associated functions are
redundant since the introduction of extmark signs.
Solution: Store signs defined through the legacy commands in a hashmap, placed
signs in the extmark tree. Replace signlist associated functions.
Usage of the legacy sign commands should yield no change in behavior with the
exception of:
- "orphaned signs" are now always removed when the line it is placed on is
deleted. This used to depend on the value of 'signcolumn'.
- It is no longer possible to place multiple signs with the same identifier
in a single group on multiple lines. This will now move the sign instead.
Moreover, both signs placed through the legacy sign commands and through
|nvim_buf_set_extmark()|:
- Will show up in both |sign-place| and |nvim_buf_get_extmarks()|.
- Are displayed by increasing sign identifier, left to right.
Extmark signs used to be ordered decreasingly as opposed to legacy signs.
Problem: buffer text with composing chars are converted from UTF-8
to an array of up to seven UTF-32 values and then converted back
to UTF-8 strings.
Solution: Convert buffer text directly to UTF-8 based schar_T values.
The limit of the text size is now in schar_T bytes, which is currently
31+1 but easily could be raised as it no longer multiplies the size
of the entire screen grid when not used, the full size is only required
for temporary scratch buffers.
Also does some general cleanup to win_line text handling, which was
unnecessarily complicated due to multibyte rendering being an "opt-in"
feature long ago. Nowadays, a char is just a char, regardless if it consists
of one ASCII byte or multiple bytes.
Problem: [security]: Use-after-free in win_close()
Solution: Check window is valid, before accessing it
If the current window structure is no longer valid (because a previous
autocommand has already freed this window), fail and return before
attempting to set win->w_closing variable.
Add a test to trigger ASAN in CI
25aabc2b8e
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: buffer-overflow in trunc_string()
Solution: Add NULL at end of buffer
Currently trunc_string() assumes that when the string is too long,
buf[e-1] will always be writeable. But that assumption may not always be
true. The condition currently looks like this
else if (e + 3 < buflen)
[...]
else
{
// can't fit in the "...", just truncate it
buf[e - 1] = NUL;
}
but this means, we may run into the last else clause with e still being
larger than buflen. So a buffer overflow occurs.
So instead of using `buf[e - 1]`, let's just always
truncate at `buf[buflen - 1]` which should always be writable.
3bd7fa12e1
vim-patch:9.0.2004: Missing test file
Problem: Missing test file
Solution: git-add the file to the repo
closes: vim/vim#13305d4afbdd071
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: Trailing white space in tests
Solution: Delete it
This causes test_codestyle to fail, so we need to remove it again.
Hopefully that makes the CI green again.
Note: I will start using annotated tags from now on.
da200c2f78
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: tests running sh have problems
Solution: Check that dash is installed
closes: vim/vim#130401690ec64ff
Co-authored-by: Philip H <47042125+pheiduck@users.noreply.github.com>
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: heap-buffer-overflow in vim_regsub_both
Solution: Disallow exchanging windows when textlock is active
f6d28fe2c9
Cherry-pick test_crash.vim change from patch 9.0.1876.
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: crash with bt_quickfix1_poc when cleaning up
and EXITFREE is defined
Solution: Test if buffer is valid in a window, else close
window directly, don't try to access buffer properties
While at it, increase the crash timeout slightly, so that CI has a
chance to finish processing the test_crash() test.
623ba31821
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: heap-use-after-free in bt_normal()
Solution: check that buffer is still valid
6e60cf444a
Test change only.
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: heap use after free in ins_compl_get_exp()
Solution: validate buffer before accessing it
ee9166eb3b
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: heap-use-after-free in is_qf_win()
Solution: Check buffer is valid before accessing it
fc68299d43
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: test_crash1() fails on CI
Solution: don't run Screendump test, verify that it doesn't crash
by running it through a shell command line, testing
the exit value and concatenating success cmd using '&&'
db510ca805
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: FPE in adjust_plines_for_skipcol
Solution: don't divide by zero, return zero
Prevent a floating point exception when calculating w_skipcol (which can
happen with a small window when the number option is set and cpo+=n).
Add a test to verify
cb0b99f067
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: overflow in get_number
Solution: Return 0 when the count gets too large
[security]: overflow in get_number
When using the z= command, we may overflow the count with values larger
than MAX_INT. So verify that we do not overflow and in case when an
overflow is detected, simply return 0
73b2d3790c
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: overflow in ex address parsing
Solution: Verify that lnum is positive, before substracting from
LONG_MAX
[security]: overflow in ex address parsing
When parsing relative ex addresses one may unintentionally cause an
overflow (because LONG_MAX - lnum will overflow for negative addresses).
So verify that lnum is actually positive before doing the overflow
check.
060623e4a3
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: overflow in nv_z_get_count
Solution: break out, if count is too large
When getting the count for a normal z command, it may overflow for large
counts given. So verify, that we can safely store the result in a long.
58f9befca1
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: overflow with count for :s command
Solution: Abort the :s command if the count is too large
If the count after the :s command is larger than what fits into a
(signed) long variable, abort with e_value_too_large.
Adds a test with INT_MAX as count and verify it correctly fails.
It seems the return value on Windows using mingw compiler wraps around,
so the initial test using :s/./b/9999999999999999999999999990 doesn't
fail there, since the count is wrapping around several times and finally
is no longer larger than 2147483647. So let's just use 2147483647 in the
test, which hopefully will always cause a failure
ac63787734
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: Test for expanding "~" in substitute takes too long.
Solution: Disable the test for now.
916d6dd5b1
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Crash when expanding "~" in substitute causes very long text.
Solution: Limit the text length to MAXCOL.
ab9a2d884b
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Use the XTGETTCAP sequence to determine if the host terminal supports
the OSC 52 sequence and, if it does, enable the OSC 52 clipboard
provider by default.
This is only done automatically when all of the following are true:
1. Nvim is running in the TUI
2. 'clipboard' is not set to unnamed or unnamedplus
3. g:clipboard is unset
4. Nvim is running in an SSH connection ($SSH_TTY is set)
5. Nvim is not running inside tmux ($TMUX is unset)
When writing large amounts of data to the tty it is common to first hide
the cursor to avoid a flickering effect. This has been done in Nvim for
a long time and was implemented in the function that actually flushed
the TUI buffer out to the TTY.
However, when using synchronized updates with the 'termsync' option this
is no longer necessary, as the terminal emulator will buffer all of the
updates and display them atomically. Thus there is no need to toggle the
cursor visibility when flushing the buffer when synchronized updates are
used. In fact, doing so can actually reintroduce cursor flickering in
certain scenarios because the visibility state is itself being
synchronized by the terminal.
In addition, the management of the cursor visibility should not happen
when the TUI _buffer_ is flushed, but rather when the TUI itself is
flushed. This is a subtle but meaningful distinction: the former
literally writes bytes to the TTY while the latter flushes the TUI's
grid into its buffer. There is no need to hide the cursor every time we
write bytes to the TTY, only at the beginning of a full TUI "flush"
event.
