kevin/neovim
1
Fork 0
mirror of https://github.com/neovim/neovim.git synced 2024-12-25 13:45:15 -07:00
Code Issues Packages Projects Releases Wiki Activity
f5231d61a5
neovim/test/unit/tui_spec.lua

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

163 lines
5.6 KiB
Lua
Raw Normal View History

tui: improve handle_background_color: short-circuit (#11067) * 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.
2019-09-30 13:00:55 -07:00
local helpers = require("test.unit.helpers")(after_each)
local cimport = helpers.cimport
local eq = helpers.eq
local ffi = helpers.ffi
local itp = helpers.gen_itp(it)
local to_cstr = helpers.to_cstr
local cinput = cimport("./src/nvim/tui/input.h")
local rbuffer = cimport("./test/unit/fixtures/rbuffer.h")
local globals = cimport("./src/nvim/globals.h")
local multiqueue = cimport("./test/unit/fixtures/multiqueue.h")
fix(unittests): fix TUI broken test previously ignored
2023-01-18 05:59:40 -07:00
local ui_client = cimport("./src/nvim/ui_client.h")
tui: improve handle_background_color: short-circuit (#11067) * 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.
2019-09-30 13:00:55 -07:00
itp('handle_background_color', function()
refactor(tests): run unittests using main nvim binary in interpreter mode This allows us to get rid of the separate "nvim-test" target
2023-01-30 12:36:49 -07:00
local handle_background_color = cinput.handle_background_color
tui: improve handle_background_color: short-circuit (#11067) * 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.
2019-09-30 13:00:55 -07:00
local term_input = ffi.new('TermInput', {})
local events = globals.main_loop.thread_events
test,unit: Change test according to change of bg color response processing Adjust the test for handle_background_color() according to bd0275182b1c1b14c43dc4fc7e9f9da05071e56c.
2020-03-11 20:16:10 -07:00
local kIncomplete = cinput.kIncomplete
local kNotApplicable = cinput.kNotApplicable
local kComplete = cinput.kComplete
tui: improve handle_background_color: short-circuit (#11067) * 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.
2019-09-30 13:00:55 -07:00
-- Short-circuit when not waiting for response.
tui: fix handling of bg response after suspend (#11145) `tui_terminal_after_startup` gets called right after resuming from suspending (via `Ctrl-z`) already (not delayed as with the startup itself), and would set `waiting_for_bg_response` to false then directly. This results in the terminal response not being processed then anymore, and leaking into Neovim itself. This changes it to try 5 times always, which means that it typically would stop after a few characters of input from the user typically, e.g. with tmux, which does not send a reply. While it might be better to have something based on the time (e.g. only wait for max 1s), this appears to be easier to do. Fixes regression in 8a4ae3d.
2019-10-02 23:04:24 -07:00
term_input.waiting_for_bg_response = 0
test,unit: Change test according to change of bg color response processing Adjust the test for handle_background_color() according to bd0275182b1c1b14c43dc4fc7e9f9da05071e56c.
2020-03-11 20:16:10 -07:00
eq(kNotApplicable, handle_background_color(term_input))
tui: improve handle_background_color: short-circuit (#11067) * 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.
2019-09-30 13:00:55 -07:00
local capacity = 100
local rbuf = ffi.gc(rbuffer.rbuffer_new(capacity), rbuffer.rbuffer_free)
term_input.read_stream.buffer = rbuf
local function assert_bg(colorspace, color, bg)
local term_response = '\027]11;'..colorspace..':'..color..'\007'
rbuffer.rbuffer_write(rbuf, to_cstr(term_response), #term_response)
tui: fix handling of bg response after suspend (#11145) `tui_terminal_after_startup` gets called right after resuming from suspending (via `Ctrl-z`) already (not delayed as with the startup itself), and would set `waiting_for_bg_response` to false then directly. This results in the terminal response not being processed then anymore, and leaking into Neovim itself. This changes it to try 5 times always, which means that it typically would stop after a few characters of input from the user typically, e.g. with tmux, which does not send a reply. While it might be better to have something based on the time (e.g. only wait for max 1s), this appears to be easier to do. Fixes regression in 8a4ae3d.
2019-10-02 23:04:24 -07:00
term_input.waiting_for_bg_response = 1
test,unit: Change test according to change of bg color response processing Adjust the test for handle_background_color() according to bd0275182b1c1b14c43dc4fc7e9f9da05071e56c.
2020-03-11 20:16:10 -07:00
eq(kComplete, handle_background_color(term_input))
tui: fix handling of bg response after suspend (#11145) `tui_terminal_after_startup` gets called right after resuming from suspending (via `Ctrl-z`) already (not delayed as with the startup itself), and would set `waiting_for_bg_response` to false then directly. This results in the terminal response not being processed then anymore, and leaking into Neovim itself. This changes it to try 5 times always, which means that it typically would stop after a few characters of input from the user typically, e.g. with tmux, which does not send a reply. While it might be better to have something based on the time (e.g. only wait for max 1s), this appears to be easier to do. Fixes regression in 8a4ae3d.
2019-10-02 23:04:24 -07:00
eq(0, term_input.waiting_for_bg_response)
fix(tui): more work in the TUI
2022-05-02 12:10:01 -07:00
eq(0, multiqueue.multiqueue_size(events))
fix(unittests): fix TUI broken test previously ignored
2023-01-18 05:59:40 -07:00
eq(bg, ({[0]="light", [1] = "dark", [-1] = "none"})
[tonumber(ui_client.ui_client_bg_response)])
tui: improve handle_background_color: short-circuit (#11067) * 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.
2019-09-30 13:00:55 -07:00
-- Buffer has been consumed.
eq(0, rbuf.size)
end
assert_bg('rgb', '0000/0000/0000', 'dark')
assert_bg('rgb', 'ffff/ffff/ffff', 'light')
assert_bg('rgb', '000/000/000', 'dark')
assert_bg('rgb', 'fff/fff/fff', 'light')
assert_bg('rgb', '00/00/00', 'dark')
assert_bg('rgb', 'ff/ff/ff', 'light')
assert_bg('rgb', '0/0/0', 'dark')
assert_bg('rgb', 'f/f/f', 'light')
assert_bg('rgb', 'f/0/0', 'dark')
assert_bg('rgb', '0/f/0', 'light')
assert_bg('rgb', '0/0/f', 'dark')
assert_bg('rgb', '1/1/1', 'dark')
assert_bg('rgb', '2/2/2', 'dark')
assert_bg('rgb', '3/3/3', 'dark')
assert_bg('rgb', '4/4/4', 'dark')
assert_bg('rgb', '5/5/5', 'dark')
assert_bg('rgb', '6/6/6', 'dark')
assert_bg('rgb', '7/7/7', 'dark')
assert_bg('rgb', '8/8/8', 'light')
assert_bg('rgb', '9/9/9', 'light')
assert_bg('rgb', 'a/a/a', 'light')
assert_bg('rgb', 'b/b/b', 'light')
assert_bg('rgb', 'c/c/c', 'light')
assert_bg('rgb', 'd/d/d', 'light')
assert_bg('rgb', 'e/e/e', 'light')
assert_bg('rgb', '0/e/0', 'light')
assert_bg('rgb', '0/d/0', 'light')
assert_bg('rgb', '0/c/0', 'dark')
assert_bg('rgb', '0/b/0', 'dark')
assert_bg('rgb', 'f/0/f', 'dark')
assert_bg('rgb', 'f/1/f', 'dark')
assert_bg('rgb', 'f/2/f', 'dark')
assert_bg('rgb', 'f/3/f', 'light')
assert_bg('rgb', 'f/4/f', 'light')
assert_bg('rgba', '0000/0000/0000/0000', 'dark')
assert_bg('rgba', '0000/0000/0000/ffff', 'dark')
assert_bg('rgba', 'ffff/ffff/ffff/0000', 'light')
assert_bg('rgba', 'ffff/ffff/ffff/ffff', 'light')
assert_bg('rgba', '000/000/000/000', 'dark')
assert_bg('rgba', '000/000/000/fff', 'dark')
assert_bg('rgba', 'fff/fff/fff/000', 'light')
assert_bg('rgba', 'fff/fff/fff/fff', 'light')
assert_bg('rgba', '00/00/00/00', 'dark')
assert_bg('rgba', '00/00/00/ff', 'dark')
assert_bg('rgba', 'ff/ff/ff/00', 'light')
assert_bg('rgba', 'ff/ff/ff/ff', 'light')
assert_bg('rgba', '0/0/0/0', 'dark')
assert_bg('rgba', '0/0/0/f', 'dark')
assert_bg('rgba', 'f/f/f/0', 'light')
assert_bg('rgba', 'f/f/f/f', 'light')
test,unit: Change test according to change of bg color response processing Adjust the test for handle_background_color() according to bd0275182b1c1b14c43dc4fc7e9f9da05071e56c.
2020-03-11 20:16:10 -07:00
-- Incomplete sequence: necessarily correct behavior.
tui: improve handle_background_color: short-circuit (#11067) * 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.
2019-09-30 13:00:55 -07:00
local term_response = '\027]11;rgba:f/f/f/f' -- missing '\007
rbuffer.rbuffer_write(rbuf, to_cstr(term_response), #term_response)
tui: fix handling of bg response after suspend (#11145) `tui_terminal_after_startup` gets called right after resuming from suspending (via `Ctrl-z`) already (not delayed as with the startup itself), and would set `waiting_for_bg_response` to false then directly. This results in the terminal response not being processed then anymore, and leaking into Neovim itself. This changes it to try 5 times always, which means that it typically would stop after a few characters of input from the user typically, e.g. with tmux, which does not send a reply. While it might be better to have something based on the time (e.g. only wait for max 1s), this appears to be easier to do. Fixes regression in 8a4ae3d.
2019-10-02 23:04:24 -07:00
term_input.waiting_for_bg_response = 1
test,unit: Change test according to change of bg color response processing Adjust the test for handle_background_color() according to bd0275182b1c1b14c43dc4fc7e9f9da05071e56c.
2020-03-11 20:16:10 -07:00
eq(kIncomplete, handle_background_color(term_input))
eq(1, term_input.waiting_for_bg_response)
eq(#term_response, rbuf.size)
term_response = '\007'
rbuffer.rbuffer_write(rbuf, to_cstr(term_response), #term_response)
eq(kComplete, handle_background_color(term_input))
eq(0, term_input.waiting_for_bg_response)
fix(unittests): fix TUI broken test previously ignored
2023-01-18 05:59:40 -07:00
eq(0, tonumber(ui_client.ui_client_bg_response))
test,unit: Change test according to change of bg color response processing Adjust the test for handle_background_color() according to bd0275182b1c1b14c43dc4fc7e9f9da05071e56c.
2020-03-11 20:16:10 -07:00
eq(0, multiqueue.multiqueue_size(events))
eq(0, rbuf.size)
term_response = '\027]11;rg'
rbuffer.rbuffer_write(rbuf, to_cstr(term_response), #term_response)
term_input.waiting_for_bg_response = 1
eq(kIncomplete, handle_background_color(term_input))
eq(1, term_input.waiting_for_bg_response)
eq(#term_response, rbuf.size)
term_response = 'ba:f/f/f/f\007'
rbuffer.rbuffer_write(rbuf, to_cstr(term_response), #term_response)
eq(kComplete, handle_background_color(term_input))
tui: fix handling of bg response after suspend (#11145) `tui_terminal_after_startup` gets called right after resuming from suspending (via `Ctrl-z`) already (not delayed as with the startup itself), and would set `waiting_for_bg_response` to false then directly. This results in the terminal response not being processed then anymore, and leaking into Neovim itself. This changes it to try 5 times always, which means that it typically would stop after a few characters of input from the user typically, e.g. with tmux, which does not send a reply. While it might be better to have something based on the time (e.g. only wait for max 1s), this appears to be easier to do. Fixes regression in 8a4ae3d.
2019-10-02 23:04:24 -07:00
eq(0, term_input.waiting_for_bg_response)
tui: improve handle_background_color: short-circuit (#11067) * 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.
2019-09-30 13:00:55 -07:00
fix(unittests): fix TUI broken test previously ignored
2023-01-18 05:59:40 -07:00
eq(0, tonumber(ui_client.ui_client_bg_response))
tui: improve handle_background_color: short-circuit (#11067) * 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.
2019-09-30 13:00:55 -07:00
eq(0, multiqueue.multiqueue_size(events))
eq(0, rbuf.size)
-- Does nothing when not at start of buffer.
term_response = '123\027]11;rgba:f/f/f/f\007456'
rbuffer.rbuffer_write(rbuf, to_cstr(term_response), #term_response)
tui: fix handling of bg response after suspend (#11145) `tui_terminal_after_startup` gets called right after resuming from suspending (via `Ctrl-z`) already (not delayed as with the startup itself), and would set `waiting_for_bg_response` to false then directly. This results in the terminal response not being processed then anymore, and leaking into Neovim itself. This changes it to try 5 times always, which means that it typically would stop after a few characters of input from the user typically, e.g. with tmux, which does not send a reply. While it might be better to have something based on the time (e.g. only wait for max 1s), this appears to be easier to do. Fixes regression in 8a4ae3d.
2019-10-02 23:04:24 -07:00
term_input.waiting_for_bg_response = 3
test,unit: Change test according to change of bg color response processing Adjust the test for handle_background_color() according to bd0275182b1c1b14c43dc4fc7e9f9da05071e56c.
2020-03-11 20:16:10 -07:00
eq(kNotApplicable, handle_background_color(term_input))
tui: fix handling of bg response after suspend (#11145) `tui_terminal_after_startup` gets called right after resuming from suspending (via `Ctrl-z`) already (not delayed as with the startup itself), and would set `waiting_for_bg_response` to false then directly. This results in the terminal response not being processed then anymore, and leaking into Neovim itself. This changes it to try 5 times always, which means that it typically would stop after a few characters of input from the user typically, e.g. with tmux, which does not send a reply. While it might be better to have something based on the time (e.g. only wait for max 1s), this appears to be easier to do. Fixes regression in 8a4ae3d.
2019-10-02 23:04:24 -07:00
eq(2, term_input.waiting_for_bg_response)
tui: improve handle_background_color: short-circuit (#11067) * 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.
2019-09-30 13:00:55 -07:00
eq(0, multiqueue.multiqueue_size(events))
eq(#term_response, rbuf.size)
rbuffer.rbuffer_consumed(rbuf, #term_response)
-- Keeps trailing buffer.
term_response = '\027]11;rgba:f/f/f/f\007456'
rbuffer.rbuffer_write(rbuf, to_cstr(term_response), #term_response)
tui: fix handling of bg response after suspend (#11145) `tui_terminal_after_startup` gets called right after resuming from suspending (via `Ctrl-z`) already (not delayed as with the startup itself), and would set `waiting_for_bg_response` to false then directly. This results in the terminal response not being processed then anymore, and leaking into Neovim itself. This changes it to try 5 times always, which means that it typically would stop after a few characters of input from the user typically, e.g. with tmux, which does not send a reply. While it might be better to have something based on the time (e.g. only wait for max 1s), this appears to be easier to do. Fixes regression in 8a4ae3d.
2019-10-02 23:04:24 -07:00
term_input.waiting_for_bg_response = 1
test,unit: Change test according to change of bg color response processing Adjust the test for handle_background_color() according to bd0275182b1c1b14c43dc4fc7e9f9da05071e56c.
2020-03-11 20:16:10 -07:00
eq(kComplete, handle_background_color(term_input))
tui: fix handling of bg response after suspend (#11145) `tui_terminal_after_startup` gets called right after resuming from suspending (via `Ctrl-z`) already (not delayed as with the startup itself), and would set `waiting_for_bg_response` to false then directly. This results in the terminal response not being processed then anymore, and leaking into Neovim itself. This changes it to try 5 times always, which means that it typically would stop after a few characters of input from the user typically, e.g. with tmux, which does not send a reply. While it might be better to have something based on the time (e.g. only wait for max 1s), this appears to be easier to do. Fixes regression in 8a4ae3d.
2019-10-02 23:04:24 -07:00
eq(0, term_input.waiting_for_bg_response)
tui: improve handle_background_color: short-circuit (#11067) * 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.
2019-09-30 13:00:55 -07:00
fix(unittests): fix TUI broken test previously ignored
2023-01-18 05:59:40 -07:00
eq(0, multiqueue.multiqueue_size(events))
tui: improve handle_background_color: short-circuit (#11067) * 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.
2019-09-30 13:00:55 -07:00
eq(3, rbuf.size)
rbuffer.rbuffer_consumed(rbuf, rbuf.size)
end)
Reference in New Issue Copy Permalink