There's something funny occasionally happening when `with_history` is
used twice in the same test. It seems to be happening more frequently
since asynchronous mode was enabled by default. My guess is it has
something to do with the `C-c` keys being sent toward the end not
consistently terminating the prompt. But I'm really not sure how it
would ever get into a `then` block like it seems to:
```
Failure/Error: wait_for { session.content }.to eq('echo "hello\nworld"')
expected: "echo \"hello\\nworld\""
got: "then> echo \"hello\\"
```
Sticking to only one `with_history` per terminal session (per test)
seems to fix the flakiness.
I also removed an old test case because I could not understand why it
was necessary and so couldn't write a good description for it. Could be
we'll need to add it back in at some point.
Set ZSH_AUTOSUGGEST_COMPLETION_IGNORE to a glob pattern to have the
completion suggestion strategy never make suggestions when the buffer
matches the pattern.
This can be helpful when some completion routines you have are
particularly expensive and you want to prevent them from running
automatically on every keystroke.
See GitHub issue #463.
Set ZSH_AUTOSUGGEST_HISTORY_IGNORE to a glob pattern to have the history
and match_prev_cmd suggestion strategies never make suggestions matching
that pattern.
For example, set to "cd *" to never suggest any `cd` commands from
history (see issues #340 and #425). Or set to "?(#c50,)" to never
suggest anything 50 characters or longer (see issue #429).
Based on https://github.com/Valodim/zsh-capture-completion
`zpty -r` with a pattern seems to have some funky behavior on older
versions, giving unpredictable results
Don't use `-s` option to `zmodload`. It is not available in zsh versions
older than 5.3
If running in sync mode and a completion takes a long time, the user can
^C out of it. We need to use `always` in the strategy function or the
pty will not be destroyed in this case and the next time we go to create
it, it will fail, making the shell unusable.
User can have many different completion styles set that will modify what
they've already typed. These styles will result in suggestions that
don't match what the user has already typed. We try our best to unset
some of the more problematic ones, but add some code to fetch to
invalidate suggestions that don't match what the user's already typed.
As far as I know, `fc` makes it impossible to tell whether history items
used an actual newline character or the string "\n". Pulling from the
`$history` array gives a more accurate representation of the actual
command that was run.