When z-sy-h is enabled after autosuggestion widgets have already been
bound, partial accepting the last part of a suggestion will result in
that string being duplicated.
I was able to reproduce using the following versions of the two plugins:
- z-sy-h: dde84e1b25f059a298ce3189cddfd0778f998df3
- z-asug: ae315ded4d
and running the following commands interactively one after another:
```
zsh -df
% source path/to/zsh-autosuggestions.zsh
% source path/to/zsh-syntax-highlighting.zsh
% bindkey -e
% bindkey <alt-f> # shows 'bindkey -e-e'
```
The order of the `source` statements matters and the issue cannot be
reproduced if the two source statements are executed together on one
line.
The problem is very similar to this one:
https://github.com/zsh-users/zsh-autosuggestions/issues/126#issuecomment-217121315
See GitHub issue #483
To avoid wrapping the built-in widgets (e.g. `autosuggest-fetch`,
`autosuggest-toggle`), we were ignoring all widgets whose names start
with `autosuggest-`. This had the downside of preventing wrapping of
user-defined widgets whose names happened to also start with that
prefix.
By being more specific about the exact built-in widgets we want to avoid
wrapping, we can allow users to define widgets whose names start with
`autosuggest-`.
See GitHub issue #496.
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.
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
