Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

suggestion breaks on fast vi movement #290

Closed
IngoMeyer441 opened this issue Nov 15, 2017 · 3 comments
Closed

suggestion breaks on fast vi movement #290

IngoMeyer441 opened this issue Nov 15, 2017 · 3 comments
Labels
pull-request-welcome

Comments

@IngoMeyer441
Copy link

If the user switches to vicmd and invokes a vi movement quickly enough (within the KEYTIMEOUT interval) the suggestion preview will disappear. One possible solution is to decrease KEYTIMEOUT but that introdoces problems with key bindings that consist of multiple keys (for example cc, iw or key bindings of the surrounding module). Is this a known problem?
IngoMeyer441 added a commit to IngoMeyer441/zsh-autosuggestions that referenced this issue Nov 17, 2017
@IngoMeyer441
Fixes zsh-users#290
29cded3 
This commit removes an optimization that stops suggestion rendering
when further keys are queued for processing. This optimization can lead
to wrong results because there is no guarantee that the last queued key
will invoke the `modify` widget (it could be a vi movement for example).
In that case, no suggestion is rendered.
@IngoMeyer441
Copy link
Author

The problem is caused by an optimization in widgets.zsh. The optimization avoids getting multiple suggestions if still keys are queued for processing. However, there is no guarantee that the last key will invoke the suggestion rendering process; in my case the last key is a vi movement and no suggestion is rendered at all. In my opinion, this optimization should be removed. What do you think?

@ericfreese
Copy link
Member

ericfreese commented Nov 17, 2017 •
edited
Loading

That optimization was added as a fix for #219 and #141 (see PR #223). Ideally, we could find a way to solve this problem while still supporting the fix for #219/#141. If there's no way to satisfy both, I think we should add an option to disable this instead of removing it for everyone.

@ericfreese
Copy link
Member

This was just fixed on develop with commit 42f5a06

Will go out with the next release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
pull-request-welcome
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ericfreese @IngoMeyer441