-
Notifications
You must be signed in to change notification settings - Fork 11
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.
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
Quickly switching buffers can break the animation #2
Comments
I think it is just how Vim works. I use
Maybe it is the same problem with I think there is few ways I can get around this limitations, and it should make animations more robust. I will look into it. Thanks for feedback :) I'll keep this issue open, until I figure out a way to make animations better. |
I think I fixed this in a new release, there was timer I forgot to clear :) |
I agree, I think this fixed the not showing up at all bit. And I figured out how to easily repro the "bug" where it stays: EDIT: Actually, I guess this is sort of what you said originally. Though I suppose I'd expect the indicator to still eventually disappear after the leader input times out? |
Good point. Just checked, it disappears for me. I do I actually trying to support vim8 now and I don't see this problem there. I guess it's neovim only behaviour. I hope I can fix it by using jobs. |
So it seems to be neovim bug, when neovim is in operator-pending mode (waiting for user to finish key combination) it stops all timer callbacks (and jobs too), until the end of operator-pending mode. I don't see how I can fix it now. There is relevant neovim issue neovim/neovim#7350. |
I've got bprev and bnext bound with
<leader>
mappings which make it pretty easy to chain them together more quickly than the animation can finish.It seems like, depending on timing, I can get:
(neither of these are particularly significant to me, just figured I'd mention it, great plugin!)
The text was updated successfully, but these errors were encountered: