Strange off-by-one error when hitting <Tab> in the command line

[wookayin]

On neovim 0.9.0 or higher, hitting <Tab> 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> is nvim__buf_redraw_range, then hitting <Tab> inserts

:lua vim.api.nnvim__buf_redraw_range
             ^
             |
       extra wrong character!

Also the fuzzy matching is also mis-aligned by offset 1:

The key mapping I use for <Tab> is

  cmap <expr> <Tab>   wilder#in_context() ? wilder#next()     : "\<Tab>"

which is simply wilder#next() in this context.

[wookayin]

https://github.com/gelguy/wilder.nvim/blob/master/autoload/wilder/main.vim#L603-L632

Scenario: lua vim.ap<TAB>

s:result has:

(nvim 0.8.3, correct)

data = {
  "cmdline.match_arg": "ap",
  "query": "ap",
  "cmdline.lua_prefix": "vim."
}

(nvim 0.9.0, incorrect)

data = {
  "cmdline.match_arg": "p",
  "query": "p",
  "cmdline.lua_prefix": "vim.a"
}

In s:get_lua_completion, a helper function vim._expand_pat is used but its implementation seems to have changed.

vim._expand_pat("^vim.ap") gives:

• 0.9.x: {"api"}, 5
• 0.8.x: {"api"}, 4

But why?

[ShangjinTang]

I also get the same strange off-by-one error as above.

This commit https://github.com/wookayin/wilder.nvim/commit/9929e1090dd84a60c1d1cc0220e0e35473c99b5e can fix the issue, but it has a side-effect that the first key word will always show "No candidates found".

[vds2212]

I notice the same behavior with Neovim 0.9.3 and Windows 10.