-
-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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
complete_info()
returns incorrect index with behavior that depends on completeopt
#12230
Comments
**BUG: The inserted index value is `1` when it should be `4`**
I'm not sure why the value "1" is wrong. The help for complete_info()
does not mention what number to expect, other than that it starts at
zero.
Note that for completion with CTRL-L the search goes backwards. Thus
"fff" is the first entry found. That this is called "1" actually makes
a lot of sense.
…--
SIGFUN -- signature too funny (core dumped)
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
Thanks for getting back to me and looking into it! I guess it seems like a bug to me because set completeopt=menu,preview
set cpoptions-=<
nmap \\ iaaa<CR>bbb<CR>ccc<CR>ddd<CR>eee<CR>fff<CR>
imap , <Cmd>put =complete_info(['selected'])['selected']<CR>
imap = <Cmd>put =execute('echo((complete_info()[''items''])[complete_info()[''selected'']])')<CR> And enter the same key sequence as in the initial reproduction, just substituting the new Needing to account for forwards/backwards selection certainly seemed surprising to me and I would suspect that it would surprise many other people trying to use Is this forwards/backwards information exposed elsewhere? Was there a part of the documentation that was supposed to help me know I needed to account for direction? Is there a better way to get the current completion item? |
As stated in the original report, search is consistently backwards when |
Thanks for getting back to me and looking into it!
I guess it seems like a bug to me because
`(complete_info()['items'])[complete_info()['selected']]` gives the
wrong completion. The following vimrc demonstrates this
```vim
set completeopt=menu,preview
set cpoptions-=<
nmap \\ iaaa<CR>bbb<CR>ccc<CR>ddd<CR>eee<CR>fff<CR>
imap , <Cmd>put =complete_info(['selected'])['selected']<CR>
imap = <Cmd>put =execute('echo((complete_info()[''items''])[complete_info()[''selected'']])')<CR>
```
And enter the same key sequence as in the initial reproduction, just
substituting the new `=` to insert what `complete_info` seems to be
telling me is the selected item (`\\<C-X><C-L><C-P>=`)
![image](https://user-images.githubusercontent.com/107967151/232342283-a802ea3c-b5b9-4bab-a568-61ca3c84a4dd.png)
Needing to account for forwards/backwards selection certainly seemed
surprising to me and I would suspect that it would surprise many other
people trying to use `complete_info`. `complete_info()` doesn't seem
to expose any information on whether the search is currently in
forwards mode or backwards mode, so there's no way to tell if the
`selected` index needs to be adjusted in order to actually use it to
index into `items`. Even if it did, It also seems like a clunky
interface to have to calculate the length of
`complete_info()['items']` and subtract the selected index from it
depending on the direction, but I can understand that this might have
been done for historical reasons/consistency of behavior with other
interfaces. I can only say that coming from other projects/interfaces
this behavior really surprises me.
Is this forwards/backwards information exposed elsewhere? Was there a
part of the documentation that was supposed to help me know I needed
to account for direction? Is there a better way to get the current
completion item?
Right, the index doesn't match what is in the items list. That looks
wrong.
The code goes through some trouble to decide how to compute the index.
I don't recall why it was done this way. There might be a reason, or
it's just because it was always done this way. How to fix it depends on
that. It might be that we need to add another entry for the corrected
item index. Or add the computed item number to each item (but that
seems clumsy, finding the right item would require searching through the
list).
…--
Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke
Any sufficiently advanced bug is indistinguishable from a feature.
Rich Kulawiec
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
Start the iteration from the same point and follow the same direction as done when assigning the completion numbers. This way we remove the dependance on the completion direction and make the order of 'info' consistent. Fixes vim#12230
Problem: complete_info() returns wrong index Solution: Make order of 'info' in completion_info consistent Start the iteration from the same point and follow the same direction as done when assigning the completion numbers. This way we remove the dependence on the completion direction and make the order of 'info' consistent. closes: vim/vim#12230 closes: vim/vim#12971 vim/vim@69fb5af Co-authored-by: LemonBoy <thatlemon@gmail.com>
Problem: complete_info() returns wrong index Solution: Make order of 'info' in completion_info consistent Start the iteration from the same point and follow the same direction as done when assigning the completion numbers. This way we remove the dependence on the completion direction and make the order of 'info' consistent. closes: vim/vim#12230 closes: vim/vim#12971 vim/vim@69fb5af Co-authored-by: LemonBoy <thatlemon@gmail.com>
Problem: complete_info() returns wrong index Solution: Make order of 'info' in completion_info consistent Start the iteration from the same point and follow the same direction as done when assigning the completion numbers. This way we remove the dependence on the completion direction and make the order of 'info' consistent. closes: vim/vim#12230 closes: vim/vim#12971 vim/vim@69fb5af Co-authored-by: LemonBoy <thatlemon@gmail.com>
Steps to reproduce
complete_info()
returns incorrect index programmatically, causing problems for completion plugins relying oncomplete_info()
for nativepumenu
interoperability. There is some subtle change in behavior depending at least on ifcompletopt
includesnoselect
.See hrsh7th/nvim-cmp#1326 for more context on how this bug was discovered and neovim/neovim#22892 for the initial bug report there.
Repro path
minimal_vimrc
vim --clean -u minimal_vimrc
\\
, which is nmapped to give minimal example file<C-X><C-L>
to open linespumenu
-- with defaultcompleteopt=menu,preview
will select "fff"<C-P>
, to navigate up the list once -- selecting "eee",,,,
, imapped toput
into the buffer the value ofcomplete_info
index- The
,
was hit multiple times so that thecomplete_info
index isn't hidden behind thepumenu
and you can see the value of the indexBUG: The inserted index value is
1
when it should be4
The bug behavior is that index counts from the bottom instead of from the top. However, whether it counts from top or bottom depends on
completeopt
value.completeopt=menu,preview
completeopt=menu,preview,noselect
, then the indexing shows 2 divergent behaviorspumenu
with<C-P>
first --> you get the reversed index (counting from bottom instead of top), acting like themenu,preview
casepumenu
with<C-N>
first --> you get the expected index, counting from topExpected behaviour
Hitting
,
should insert4
from it's call tovim.fn.complete_info({'selected'}).selected
Version of Vim
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Mar 21 2023 20:51:42) Included patches: 1-1420 Compiled by Arch Linux
Environment
Operating System: Arch LInux, on WSL2 on Win11
Terminal: windows terminal
$Term: xterm-246color
Shell: bash
Logs and stack traces
No response
The text was updated successfully, but these errors were encountered: