Commit Graph

6 Commits

Author SHA1 Message Date
Johannes Altmanninger
9d8c9777a4 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-15 15:08:10 +01:00
Maxime Coste
9b166e8007 Try to fix regression/0-mouse-during-insert test flakyness 2024-01-05 15:39:30 +11:00
Maxime Coste
39be51b55c Fix regression/0-mouse-during-insert test flakyness
Do not rely on timing but wait for Kakoune to redraw which is what
we actually need: Mouse clicks rely on the current display buffer
to resolve the buffer location, so we need to wait for a redraw
to happen with `ui_out`
2023-08-05 10:58:15 +10:00
Johannes Altmanninger
566eb25d7a Give mouse-during-insert more slack on CI, it failed again on macOS 2023-04-24 18:31:05 +02:00
Johannes Altmanninger
0f55d21970 Add sleep to prevent mouse-during-insert test failure
The macOS CI manges to trigger this race.  When it happens the
"c" inserted by the last command is not seen by the test runner.
Let's fix this by adding yet another sleep.
2023-03-05 17:42:41 +01:00
Johannes Altmanninger
35f23d6fad 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.
2023-01-08 10:47:36 +01:00