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
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.
