rneovim.git - Neovim fork with Rahm's personal hacks.

	Commit message (Collapse)	Author	Age
*	refactor(tests): run unittests using main nvim binary in interpreter mode	bfredl	2023-01-31
\| \| \| \|	This allows us to get rid of the separate "nvim-test" target
*	fix(unittests): fix TUI broken test previously ignored	bfredl	2023-01-18
\|
*	fix(tui): more work in the TUI	bfredl	2022-12-31
\|
*	test,unit: Change test according to change of bg color response processing	erw7	2020-11-20
\| \| \| \| \|	Adjust the test for handle_background_color() according to bd0275182b1c1b14c43dc4fc7e9f9da05071e56c.
*	tui: fix handling of bg response after suspend (#11145)	Daniel Hahler	2019-10-03
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	`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.
*	tui: improve handle_background_color: short-circuit (#11067)	Daniel Hahler	2019-09-30
	* 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.