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.
Use case suggested by @romkatv uses zle-line-init to restore buffer
after running a widget to cd up one level (GitHub #431).
As far as I can tell, the ignoring of zle-line-* was added in commit
9788c2e to support some deprecation warnings that were removed some time
ago.
The pattern was then widened in commit 0c940e7 to zle-* to fix problems
encountered when wrapping zle-isearch-update.
This commit removes the hard coded ignore of all zle-* widgets and adds
zle-* to the default list of widgets to be ignored. Users who want the
plugin to wrap zle-line-init or zle-line-finish can override the
default.
Like {up,down}-line-or-beginning-search, this widget relies on
`$LASTWIDGET` being set to function correctly on subsequent invocations.
When asynchronous suggestions are enabled, and the widget triggers a
suggestion to be fetched, `autosuggest-suggest` will be called and
$LASTWIDGET will be set to it.
Like {up,down}-line-or-beginning-search, this widget relies on
`$LASTWIDGET` being set to function correctly on subsequent invocations.
When asynchronous suggestions are enabled, and the widget triggers a
suggestion to be fetched, `autosuggest-suggest` will be called and
$LASTWIDGET will be set to it.
Some people have gotten used to setting ZSH_AUTOSUGGEST_BUFFER_MAX_SIZE
to an empty string rather than leaving it unset. This lets them continue
to do that without getting any warnings (e.g. "bad math expression:
operand expected at end of string").
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.
