This is the last time I'm doing this before I rip these particular
tests out.
As far as I know there is no actual *problem* here, this is just
failing through a combination of macOS and Github Actions being slow
as molasses.
So it is wasting our time and therefore worse than not having these
tests at all, especially since they very rarely fail for good reasons.
We would leave some escape delay tests intact with generous timeouts, which would provide 90%
of the coverage with 10% of the hassle.
This simply checks if the parser requested exit after running any
binding scripts (in read_normal_chars).
I think this means we no longer need the `exit` bind function.
Fixes#7967.
This increases a 100ms timeout to 200ms, because we've hit it on
Github Actions:
```
INPUT 3904.65 ms (Line 223): set -g fish_escape_delay_ms 100\n
OUTPUT +1.74 ms (Line 224): \rprompt 25>
INPUT +0.71 ms (Line 230): echo abc def
INPUT +0.57 ms (Line 231): \x1b
INPUT +0.57 ms (Line 232): t\r
OUTPUT +2.41 ms (Line 234): \r\ndef abc\r\n
OUTPUT +1.63 ms (Line 234): \rprompt 26>
INPUT +0.75 ms (Line 239): echo ghi jkl
INPUT +0.57 ms (Line 240): \x1b
INPUT +134.98 ms (Line 242): t\r
```
In other places it decreases sleeps where we just wait for a timeout to elapse, in which case we don't need much longer than the timeout.
With the upcoming fix to place the tty in external-proc mode, add a sleep
which resolves a race between emitting a newline and restoring it to shell
mode.
The classic mistake: Some of these have a bit of a delay, but it's supposed to
be *under* the timeout, so it needs to be *shorter* not longer to
increase the slack.
We just had the following output on Github Actions:
INPUT +0.94 ms (Line 34): echo ghi jkl
INPUT +0.72 ms (Line 35): \x1b
INPUT +63.12 ms (Line 37): t\r
The default escape delay is 30ms, that had 60ms between an escape and
a tab, so it missed it.
So: We have to increase the delay for CI's benefit. Let's try with
80ms, because otherwise we'd have to bump up other timeouts and the
bind tests take long enough as it is.
We've heard news of this regressing, so let's add the test that should
have been there already (mea culpa!).
Because we now use POSIX_VDISABLE, this should also work in tandem
with ctrl-space (which sends NUL), but we can't test *that* because
some systems might not have POSIX_VDISABLE.
Ensure that the increment= param is set via keyword, not via positional arg.
This mistake was masking a bug where the "^a b c" match was not being tested,
because it was being set as the value for increment!
This switches the 'increment' param from "after" to "before." Instead
of expect_prompt saying if the next prompt will be incremented, each
call site says if it should have been incremented sinec the last prompt.
With a commandline like
```
a b c d
```
and the cursor at the beginning, this would eat "a b", which isn't a
sensible bigword.
Bigword should be "a word, with optional leading whitespace".
This was caused by an overly zealous state-machine that always ate one
char and only *then* started eating leading whitespace.
Instead eat *a character*, and if it was whitespace go on eating
whitespace, and if it was a printable go straight to only eating
printables.
Fixes#7325.
Prior to this change, if we saw more than one repaint readline command in
a row, we would try to ignore the second one. However this was never the
right thing to do since sometimes we really do need to repaint twice in a
row (e.g. the user hits Ctrl+L twice). Previously we were saved by the
buginess of this mechanism but with the repainting refactoring we see
missing redraws.
Remove the coalescing logic and add a test. Fixes#7280.
Make it easier to use pexpect and to understand its error messages.
Switch to a style in tests using bound methods, which makes them
less noisy to write.
This adds a new interactive test framework based on Python's pexpect. This
is intended to supplant the TCL expect-based tests.
New tests go in `tests/pexpects/`. As a proof-of-concept, the
pipeline.expect test and the (gnarly) bind.expect test are ported to the
new framework.
