We are getting errors on circle ci builds (e.g. see [1]):
```
CircleCI was unable to run the job runner because we were unable to
execute commands in build container.
This typically means that the build container entrypoint or command is
terminating the container prematurely, or interfering with executed
commands. Consider clearing entrypoint/command values and try again.
```
Folks in this thread [2] suggest removing the `command: /sbin/init` line
initially added by the v1 => v2 migration script.
---
1: https://circleci.com/gh/zsh-users/zsh-autosuggestions/381
2: https://discuss.circleci.com/t/circleci-was-unable-to-run-the-job-runner/31894/18
We are getting errors on circle ci builds (e.g. see [1]):
```
CircleCI was unable to run the job runner because we were unable to
execute commands in build container.
This typically means that the build container entrypoint or command is
terminating the container prematurely, or interfering with executed
commands. Consider clearing entrypoint/command values and try again.
```
Folks in this thread [2] suggest removing the `command: /sbin/init` line
initially added by the v1 => v2 migration script.
---
1: https://circleci.com/gh/zsh-users/zsh-autosuggestions/381
2: https://discuss.circleci.com/t/circleci-was-unable-to-run-the-job-runner/31894/18
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).
$max_cursor_pos in this case was not the correct value to use. It was
calculated based on the old length of the $BUFFER. After the suggestion
is accepted, we need to recalculate the new max cursor length and use it
to set the $CURSOR.
Fixes issue #452. Follow-up to issue #302 (PR #450).
Typing `d` and then `l` runs `vi-delete` and then `vi-forward-char`. However,
by default, `vi-forward-char` is configured to accept the suggestion. So in
that case, the suggestion was being accepted and the cursor set to the end of
the buffer before the deletion was run.
The reason the user doesn't see the suggestion accepted is that `vi-delete`
doesn't finish until the movement widget is run, so we're already inside of a
`modify` when `accept` is called. `modify` unsets `POSTDISPLAY` before calling
the original widget so when we get to the accept function, `POSTDISPLAY` is
empty and thus accepting the suggestion is a no-op.
The fix is to make sure we reset the cursor to the correct place before running
the original widget.
We skip the test for versions of zsh below 5.0.8 since there was a bug in
earlier versions where deleting the last char did not work.
See http://www.zsh.org/mla/workers/2014/msg01316.html
* Added a note for iTerm2 users under readme/configuration/highlight
style.
* Changed the link to the issue list under troubleshooting so that the
default filters (only open issues) are not applied.
When using async mode, stale background processes will not be cancelled
when a new one starts. This shouldn't cause any real issues since the
processes should eventually finish and be cleaned up anyway, and
removing the handler with `zle -F` means that stale suggestions should
never be shown.
Command substitution via $() trims trailing newlines so the old approach
to reading everything from the fd was preventing suggestions from ending
with newlines.
Found the read solution here: https://stackoverflow.com/a/15184414/154703
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.
