-
Notifications
You must be signed in to change notification settings - Fork 33
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
Strange off-by-one error when hitting <Tab> in the command line #187
Comments
https://github.com/gelguy/wilder.nvim/blob/master/autoload/wilder/main.vim#L603-L632 Scenario:
(nvim 0.8.3, correct)
(nvim 0.9.0, incorrect)
In
But why? |
A private method vim._expand_pat (which should not be used) has changed the behavior, which causes an off-by-one error in completion. As a temporary workaround, we manually offset the match position.
I also get the same strange off-by-one error as above. This commit wookayin@9929e10 can fix the issue, but it has a side-effect that the first key word will always show "No candidates found". |
I notice the same behavior with Neovim 0.9.3 and Windows 10. |
On neovim 0.9.0 or higher, hitting to insert and accept the completion suggestion would result in an off-by-one error:
For example, if the first completion item for
:lua vim.api.<Tab>
isnvim__buf_redraw_range
, then hitting<Tab>
insertsAlso the fuzzy matching is also mis-aligned by offset 1:
The key mapping I use for
<Tab>
iswhich is simply
wilder#next()
in this context.The text was updated successfully, but these errors were encountered: