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.
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.
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
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
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.
In zsh source, see main zle event loop in zle_main.c raw_getbyte
function.
If running in sync mode and a completion takes a long time, the user can
^C out of it. Without this patch, 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.
Error looked something like:
```
% echo 'f(zpty):8: unmatched '
_zsh_autosuggest_capture_completion:zpty:9: no such pty command: zsh_autosuggest_completion_pty
_zsh_autosuggest_capture_completion:zpty:14: no such pty command: zsh_autosuggest_completion_pty
_zsh_autosuggest_capture_completion:zpty:21: no such pty command: zsh_autosuggest_completion_pty
```
According to `man zshmodules`, the args to `zpty` are "concatenated with
spaces between, then executed as a command, as if passed to the eval
builtin." So we need to escape the `$` so that `$1` is passed to eval
instead of the value of `$1`.
The `zsh -f` running in the PTY doesn't know about the non-exported
variables and functions defined in the original shell, thus can't make
suggestions for them. Run local functions in the PTY instead of a new
`zsh` process.
We have to handle things differently based on whether zle is active or
not (async vs. sync mode).
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.
`_zsh_autosuggest_widget_accept()` (&al.) passes this function's return status
on, and ZLE rings the bell if it's >0. Not having an original widget isn't an
error condition, so always returning 0 here should be OK to avoid the bell
Fixes#228
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.
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")
It seems like all the zle-* methods are special and shouldn't be
monkeyed with.
Specifically `zle-isearch-update` and friends. Binding that widget
caused `history-incremental-pattern-search` to stop working.
Fixeszsh-users/zsh-syntax-highlighting#387
