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.
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.
See technique used in `fast-syntax-highlighting`:
- ca2e18bbc9
- http://www.zsh.org/mla/users/2018/msg00424.html
Also see http://www.zsh.org/mla/users/2018/msg00432.html
In async response handler:
- We only want to read data in case of POLLIN or POLLHUP. Not POLLNVAL
or select error.
- We always want to remove the handler, so it doesn't get called in an
infinite loop when error is nval or err.
There is an upstream bug that prevents ctrl-c from resetting the prompt
immediately after a suggestion has been fetched asynchronously. A patch
has been submitted, but a workaround for now is to add `command true`
after the exec.
See https://github.com/zsh-users/zsh-autosuggestions/issues/364
otherwise users are obliged to set the config values *after* sourcing
the plugin. They're not able to do it before. Also, re-sourcing the
plugin will reset the values to the defaults again.
See zimfw/zimfw#301
Fixes#335
For unknown reasons, the pty will occasionally quit running. In these
cases, we still want to remove it so that a fresh one can be created. We
don't actually need this check because error messages from `zle` and
`zpty` are redirected to /dev/null.
One sure way to kill all currently running pty's is to run `exit` in a
subshell. Even without zsh-autosuggestions loaded, the following works:
% zmodload zsh/zpty
% zpty -b foo cat
% zpty -b bar cat
% zpty
(31689) bar: cat
(31666) foo: cat
% $(exit)
% zpty
(finished) bar: cat
(finished) foo: cat
Specific case where this matters is following:
Be in vi insert mode with some text in the buffer and the cursor at the
end of the buffer. Press `esc` to trigger `vi-cmd-mode widget`, then
before the cursor moves (KEYTIMEOUT), press `h` to trigger
`vi-backward-char` widget. When `vi-cmd-mode` original widget exits,
KEYS_QUEUED_COUNT will be non-zero and the suggestion will be lost.
These widgets rely on `$LASTWIDGET` being set to restore the cursor
position. 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.
This fixes a small issue in src/widgets.zsh which makes it so if you
alias [ to g[ (as is done in prezto if the gnu-utility module is loaded)
autosuggestions would fail.
The documentation for GNU test mentions that -o and -a should be avoided
if possible because it's not very clear. Also, with zsh and [[ -o
actually tests if an option is set, which makes this option even more
confusing.
Seems like this would happen on some machines but not on others. Not
sure exactly what's going on, but this is such an edge case I'm just
going to remove the test.
