Included patches:
821. By Paul "LeoNerd" Evans on 2022-12-29
Don't bother to emit the unrecognised sequence in DECRQSS response as it provides an echo roundtrip possibility
820. By Paul "LeoNerd" Evans on 2022-11-26
erase_internal() should only set fg/bg colour, resetting other attributes (especially RV)
819. By Paul "LeoNerd" Evans on 2022-11-09
Added vterm_screen_set_default_colors(), which repaints the cells in the buffer(s)
818. By Paul "LeoNerd" Evans on 2022-11-09
Permit either colour argument to be NULL to vterm_state_set_default_colors()
817. By Paul "LeoNerd" Evans on 2022-10-01
Delete the mk_wcswidth functions as they're not used; guard the CJK-wide one with an ifdef as by default we don't use it
816. By Paul "LeoNerd" Evans on 2022-10-01
Make sure to supply empty (void) prototype to functions that take no arguments in bin/vterm-ctrl.c
Problem: When unibi_format() modifies params and data->buf overflows,
unibi_format() is called again, causing the params to be
modified twice. This can happen for escapes sequences that
use the %i terminfo format specifier (e.g. cursor_address),
which makes unibi_format() increase the param by 1.
Solution: Make a copy of data->params before calling unibi_format().
Now that the TUI calls nvim_paste and nvim_input through RPC, the data
race is much more likely, as nvim_paste is deferred while nvim_input is
not. Add an expect_child_buf_lines() call to avoid the race.
Extend the capabilities of is_os to detect more platforms such as
freebsd and openbsd. Also remove `iswin()` helper function as it can be
replaced by `is_os("win")`.
This is essentially a convenience wrapper around the `pending()`
function, similar to `skip_fragile()` but more general-purpose.
Also remove `pending_win32` function as it can be replaced by
`skip(iswin())`.
Problem: Command overlaps with printed text in scrollback.
Solution: Clear until end-of-line and use correct message chunk.
(closesvim/vim#10765, closesvim/vim#10764)
ecdc82e74e
N/A patches for version.c:
vim-patch:9.0.0070: using utfc_ptr2char_len() when length is negative
Problem: Using utfc_ptr2char_len() when length is negative.
Solution: Check value of length. (closesvim/vim#10760)
4dc513a22c
* fix(test): screen.lua nil index
When actual_rows and expected_rows are different avoid a nil index.
* fix(tui): resize at startup
The deleted code is not needed after 402b4e8.
It caused the condition to false positive when the function was called
more than once before startup (first normal mode). Being itself what
set the dimension and not the user, locking the size of the screen to
an incorrect size.
Make got_winch an int to mitigate: tui_grid_resize changing the size
of the host terminal between the signal handler and the call to
sigwinch_cb. Since the actual signal handler uv__signal_handle doesn't
directly call the callback, the event loop does.
Fixes#17285Fixes#15044Fixes#11330
This make Nvim recognize `ESC NUL` as <M-C-Space>, as many terminal
emulators (including libvterm) send <M-C-Space> as `ESC NUL`.
There is already another unambiguous way to encode a `ESC` key supported
by libtermkey: `ESC [ 2 7 u`, which is a `CSI u` sequence.
If one still wants to use `ESC NUL` as `ESC`, they can just map
<M-C-Space> to <Esc>.
The Lua modules that make up vim.lua are embedded as raw source files into the
nvim binary. These sources are loaded by the Lua runtime on startuptime. We can
pre-compile these sources into Lua bytecode before embedding them into the
binary, which minimizes the size of the binary and improves startuptime.
After PR #8226 an unmapped META key in insert mode behaves like
ESC-<key> (:help i_META).
The behaviour does not fully match, since if <Esc>-<key> is pressed
manually then since it were pressed manually `gotchars` would be called
on the second <key> after insert-mode had already been left.
This would mean that `may_sync_undo` (called from `gotchars`) would
call `u_sync(FALSE)` on the second key (since we would be in normal
mode).
This overall means that <Meta-[something]> behaves differently with
respect to undo than <Esc>[something] when the [something] makes a
change.
As an example, under `nvim -u NONE`:
ihello<M-.>u
leaves the buffer empty, while
ihello<Esc>.u
leaves the buffer with one instance of `hello`.
- Fix by calling u_sync() manually in the new clause under
`normalchar:` in `insert_handle_key`.
- Update test in tui_spec.lua that accidentally relied on the old behaviour.
- We already find ourselves renaming nvim_execute_lua in tests and
scripts, which suggests "exec" is the verb we actually want.
- Add "exec" verb to `:help dev-api`.
It is perfectly fine and expected to detach from the screen just by
the UI disconnecting from nvim or exiting nvim. Just keep detach() in
screen_basic_spec, to get some coverage of the detach method itself.
This avoids hang on failure in many situations (though one could argue
that detach() should be "fast", or at least "as fast as resize",
which works in press-return already).
Never use detach() just to change the size of the screen, try_resize()
method exists for that specifically.
Meant to fix:
[ ERROR ] test/functional/terminal/tui_spec.lua @ 925: TUI FocusGained/FocusLost in terminal-mode
test/functional/ui/screen.lua:587: Row 6 did not match.
Expected:
|{1:r}eady $ |
|[Process exited 0] |
| |
| |
| |
|*gained |
|{3:-- TERMINAL --} |
Actual:
|{1:r}eady $ |
|[Process exited 0] |
| |
| |
| |
|*:terminal |
|{3:-- TERMINAL --} |
To print the expect() call that would assert the current screen state, use
screen:snapshot_util(). In case of non-deterministic failures, use
screen:redraw_debug() to show all intermediate screen states.
stack traceback:
test/functional/ui/screen.lua:587: in function '_wait'
test/functional/ui/screen.lua:370: in function 'expect'
test/functional/terminal/tui_spec.lua:934: in function <test/functional/terminal/tui_spec.lua:925>
I've thought about adding this, but it might not be really relevant, and
slows down the tests a bit (and a warning "warning: Screen test
succeeded immediately" with another test):
```diff
diff --git i/test/functional/terminal/tui_spec.lua w/test/functional/terminal/tui_spec.lua
index ada073c4e..4bc2ab4e0 100644
--- i/test/functional/terminal/tui_spec.lua
+++ w/test/functional/terminal/tui_spec.lua
@@ -818,6 +818,11 @@ describe('TUI FocusGained/FocusLost', function()
..'", "-u", "NONE", "-i", "NONE", "--cmd", "set noswapfile noshowcmd noruler"]')
feed_data(":autocmd FocusGained * echo 'gained'\n")
feed_data(":autocmd FocusLost * echo 'lost'\n")
+ -- Wait for autocommand to be registered.
+ retry(nil, nil, function()
+ feed_data(":autocmd FocusLost\n")
+ screen:expect{any=" echo 'lost'"}
+ end)
feed_data("\034\016") -- CTRL-\ CTRL-N
end)
```
* handle_background_color: short-circuit if handled already
* Unit tests for handle_background_color
* set waiting_for_bg_response to false in tui_terminal_after_startup
By then it should have been received.
Doing the screen test first might give insights about a possible
(flaky?) failure, where it looks like "feed_data" is processed out of
order:
[ ERROR ] test/functional/terminal/tui_spec.lua @ 561: TUI paste: exactly 64 bytes #10311
test/functional/helpers.lua:388:
retry() attempts: 490
test/functional/terminal/tui_spec.lua:66: Expected objects to be the same.
Passed in:
(table: 0x44042de8) {
*[1] = ' endzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz' }
Expected:
(table: 0x41d6e568) {
*[1] = 'zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz end' }
stack traceback:
test/functional/helpers.lua:388: in function 'retry'
test/functional/terminal/tui_spec.lua:63: in function 'expect_child_buf_lines'
test/functional/terminal/tui_spec.lua:569: in function <test/functional/terminal/tui_spec.lua:561>
Ref: https://github.com/neovim/neovim/pull/11083#issuecomment-534375201
Build log: https://travis-ci.org/neovim/neovim/jobs/588749739#L5597
Before this, --embed UIs (without --headless) would not trigger UIEnter.
For TUI, maybe UIEnter isn't useful, but:
- It is less "surprising"/special.
- Makes documentation simpler.
- When TUI becomes a coprocess, it will happen anyway.
