kakoune/test/regression/0-mouse-during-insert/script

ui_out -ignore 7
ui_in '{ "jsonrpc": "2.0", "method": "keys", "params": [ "i" ] }'
ui_out -ignore 4
ui_in '{ "jsonrpc": "2.0", "method": "keys", "params": [ "a" ] }'
ui_out -ignore 4
ui_in '{ "jsonrpc": "2.0", "method": "mouse_press", "params": [ "left", 0, 2 ] }'
ui_out -ignore 4
ui_in '{ "jsonrpc": "2.0", "method": "keys", "params": [ "b" ] }'
ui_out -ignore 4
ui_in '{ "jsonrpc": "2.0", "method": "mouse_release", "params": [ "left", 0, 4 ] }'
ui_out -ignore 4
ui_in '{ "jsonrpc": "2.0", "method": "keys", "params": [ "c<esc>" ] }'
ui_out -ignore 4
Try to fix regression/0-mouse-during-insert test flakyness 2024-01-05 05:39:30 +01:00			`ui_out -ignore 7`
Remove bogus assertions preventing mouse clicks in insert mode Recent changes for selection-undo added an assertion that triggers when a mouse-drag overlaps with an insert mode, because both events record selection history. However this is actually fine. The one that finishes last concludes the selection edition, while the other one will be a nop. The test could be simpler (i.e. not require sleeps) but I figured it doesn't hurt add this since we don't have any comparable tests. 2022-12-03 19:00:46 +01:00			`ui_in '{ "jsonrpc": "2.0", "method": "keys", "params": [ "i" ] }'`
Await all UI events after each key press in mouse-during-insert test This test doesn't care about testing things like "if I send the next key before we have finished reacting to the previous ones, nothing bad ever happens". Hence we can until exhaustion after each input. This should fix bespoke flakiness. The handling of "c<esc>" should be atomic. This reasoning probably applies to most tests; waiting for all events seems like the safest and easiest approach overall (compared to sleep or sleep-until). The downside is that the tests need changes when UI code changes but it rarely does, and if it does we can automate the updates. Closes #5073 2024-01-13 14:18:18 +01:00			`ui_out -ignore 4`
Remove bogus assertions preventing mouse clicks in insert mode Recent changes for selection-undo added an assertion that triggers when a mouse-drag overlaps with an insert mode, because both events record selection history. However this is actually fine. The one that finishes last concludes the selection edition, while the other one will be a nop. The test could be simpler (i.e. not require sleeps) but I figured it doesn't hurt add this since we don't have any comparable tests. 2022-12-03 19:00:46 +01:00			`ui_in '{ "jsonrpc": "2.0", "method": "keys", "params": [ "a" ] }'`
Await all UI events after each key press in mouse-during-insert test This test doesn't care about testing things like "if I send the next key before we have finished reacting to the previous ones, nothing bad ever happens". Hence we can until exhaustion after each input. This should fix bespoke flakiness. The handling of "c<esc>" should be atomic. This reasoning probably applies to most tests; waiting for all events seems like the safest and easiest approach overall (compared to sleep or sleep-until). The downside is that the tests need changes when UI code changes but it rarely does, and if it does we can automate the updates. Closes #5073 2024-01-13 14:18:18 +01:00			`ui_out -ignore 4`
Remove bogus assertions preventing mouse clicks in insert mode Recent changes for selection-undo added an assertion that triggers when a mouse-drag overlaps with an insert mode, because both events record selection history. However this is actually fine. The one that finishes last concludes the selection edition, while the other one will be a nop. The test could be simpler (i.e. not require sleeps) but I figured it doesn't hurt add this since we don't have any comparable tests. 2022-12-03 19:00:46 +01:00			`ui_in '{ "jsonrpc": "2.0", "method": "mouse_press", "params": [ "left", 0, 2 ] }'`
Await all UI events after each key press in mouse-during-insert test This test doesn't care about testing things like "if I send the next key before we have finished reacting to the previous ones, nothing bad ever happens". Hence we can until exhaustion after each input. This should fix bespoke flakiness. The handling of "c<esc>" should be atomic. This reasoning probably applies to most tests; waiting for all events seems like the safest and easiest approach overall (compared to sleep or sleep-until). The downside is that the tests need changes when UI code changes but it rarely does, and if it does we can automate the updates. Closes #5073 2024-01-13 14:18:18 +01:00			`ui_out -ignore 4`
Remove bogus assertions preventing mouse clicks in insert mode Recent changes for selection-undo added an assertion that triggers when a mouse-drag overlaps with an insert mode, because both events record selection history. However this is actually fine. The one that finishes last concludes the selection edition, while the other one will be a nop. The test could be simpler (i.e. not require sleeps) but I figured it doesn't hurt add this since we don't have any comparable tests. 2022-12-03 19:00:46 +01:00			`ui_in '{ "jsonrpc": "2.0", "method": "keys", "params": [ "b" ] }'`
Await all UI events after each key press in mouse-during-insert test This test doesn't care about testing things like "if I send the next key before we have finished reacting to the previous ones, nothing bad ever happens". Hence we can until exhaustion after each input. This should fix bespoke flakiness. The handling of "c<esc>" should be atomic. This reasoning probably applies to most tests; waiting for all events seems like the safest and easiest approach overall (compared to sleep or sleep-until). The downside is that the tests need changes when UI code changes but it rarely does, and if it does we can automate the updates. Closes #5073 2024-01-13 14:18:18 +01:00			`ui_out -ignore 4`
Remove bogus assertions preventing mouse clicks in insert mode Recent changes for selection-undo added an assertion that triggers when a mouse-drag overlaps with an insert mode, because both events record selection history. However this is actually fine. The one that finishes last concludes the selection edition, while the other one will be a nop. The test could be simpler (i.e. not require sleeps) but I figured it doesn't hurt add this since we don't have any comparable tests. 2022-12-03 19:00:46 +01:00			`ui_in '{ "jsonrpc": "2.0", "method": "mouse_release", "params": [ "left", 0, 4 ] }'`
Await all UI events after each key press in mouse-during-insert test This test doesn't care about testing things like "if I send the next key before we have finished reacting to the previous ones, nothing bad ever happens". Hence we can until exhaustion after each input. This should fix bespoke flakiness. The handling of "c<esc>" should be atomic. This reasoning probably applies to most tests; waiting for all events seems like the safest and easiest approach overall (compared to sleep or sleep-until). The downside is that the tests need changes when UI code changes but it rarely does, and if it does we can automate the updates. Closes #5073 2024-01-13 14:18:18 +01:00			`ui_out -ignore 4`
Remove bogus assertions preventing mouse clicks in insert mode Recent changes for selection-undo added an assertion that triggers when a mouse-drag overlaps with an insert mode, because both events record selection history. However this is actually fine. The one that finishes last concludes the selection edition, while the other one will be a nop. The test could be simpler (i.e. not require sleeps) but I figured it doesn't hurt add this since we don't have any comparable tests. 2022-12-03 19:00:46 +01:00			`ui_in '{ "jsonrpc": "2.0", "method": "keys", "params": [ "c<esc>" ] }'`
Await all UI events after each key press in mouse-during-insert test This test doesn't care about testing things like "if I send the next key before we have finished reacting to the previous ones, nothing bad ever happens". Hence we can until exhaustion after each input. This should fix bespoke flakiness. The handling of "c<esc>" should be atomic. This reasoning probably applies to most tests; waiting for all events seems like the safest and easiest approach overall (compared to sleep or sleep-until). The downside is that the tests need changes when UI code changes but it rarely does, and if it does we can automate the updates. Closes #5073 2024-01-13 14:18:18 +01:00			`ui_out -ignore 4`