Just remove up to and including the first null byte and after and
including the last null byte.
I also looked into using `${${(0)line}[2]}`, but it fails when `$line`
starts with a null byte, since the first split string will be empty and
thus not included in the resulting array.
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.
Maybe this is also a fix for #247, #248 and #258. Supersedes #267.
Testcase:
Using match_prev_cmd strategy and with these lines in history:
echo '1^'
echo '2^'
echo '1^'
type:
echo (unexpected suggestion echo '1^' instead of echo '2^')
echo '1^1 (wrong suggestion echo '1^1echo '1^')
echo '1^# (error "bad math expression")
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.
According to a few tests, the `fc` builtin appears to be quite a bit
faster than searching through the `$history` associative array when
dealing with large history files (500K+).
This strategy relies on the history being exactly in the order in which
commands have been entered. Therefore, options like suppressing
duplicates or expiring duplicates first will lead to unexpected
suggestions.
A new suggestion strategy 'match_prev_cmd' is available. This is a bit
more context aware variaton on the default strategy.
The suggestion will be:
- The newest history entry that matches the current prefix, AND
- Whose preceding history entry also matches the previously executed
command.
See src/strategies/match_prev_cmd.zsh for an example.