[vim/vim] `getcompletion('e', 'command')` returns empty list when `set wildoptions=fuzzy` (Issue #9986)

18 views
Skip to first unread message

バクダンくん

unread,
Mar 21, 2022, 3:17:35 AM3/21/22
to vim/vim, Subscribed

Steps to reproduce

  1. vim --clean
  2. Confirm :echo getcompletion('e', 'command') returns many commands
  3. :set wildoptions=fuzzy
  4. Confirm :echo getcompletion('e', 'command') returns empty list

Expected behaviour

getcompletion() does not take effect of 'wildoptions'.

Actually I want getcompletion('e', 'command') to take effect of 'wildoptions' and returns commands that are same as what are shown when I hit :e<Tab>, but that can break some plugins.
It may be good to add fourth argument to getcompletion() to specify whether to use fuzzy completion.

Version of Vim

8.2.4522

Environment

OS: Windows 11 Pro
Terminal: Windows Terminal and GUI

Logs and stack traces

No response

—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/9986@github.com>

Yegappan Lakshmanan

unread,
Mar 21, 2022, 2:11:00 PM3/21/22
to vim_dev, reply+ACY5DGAVJARYSSHB4R...@reply.github.com, vim/vim, Subscribed
Hi,

On Mon, Mar 21, 2022 at 12:17 AM バクダンくん <vim-dev...@256bit.org> wrote:

Steps to reproduce

  1. vim --clean
  2. Confirm :echo getcompletion('e', 'command') returns many commands
  3. :set wildoptions=fuzzy
  4. Confirm :echo getcompletion('e', 'command') returns empty list

Expected behaviour

getcompletion() does not take effect of 'wildoptions'.

Actually I want getcompletion('e', 'command') to take effect of 'wildoptions' and returns commands that are same as what are shown when I hit :e<Tab>, but that can break some plugins.
It may be good to add fourth argument to getcompletion() to specify whether to use fuzzy completion.


I see the problem. I will modify getcompletion() to check for the 'wildoptions' values.
A plugin can save/restore the 'wildoptions' setting if needed to get the completion
matches with fuzzy matching and without fuzzy matching.

- Yegappan

vim-dev ML

unread,
Mar 21, 2022, 2:11:16 PM3/21/22
to vim/vim, vim-dev ML, Your activity

Hi,

On Mon, Mar 21, 2022 at 12:17 AM バクダンくん ***@***.***> wrote:

> Steps to reproduce
>
> 1. vim --clean
> 2. Confirm :echo getcompletion('e', 'command') returns many commands
> 3. :set wildoptions=fuzzy
> 4. Confirm :echo getcompletion('e', 'command') returns empty list

>
> Expected behaviour
>
> getcompletion() does not take effect of 'wildoptions'.
>
> Actually I want getcompletion('e', 'command') to take effect of
> 'wildoptions' and returns commands that are same as what are shown when I
> hit :e<Tab>, but that can break some plugins.
> It may be good to add fourth argument to getcompletion() to specify
> whether to use fuzzy completion.
>

I see the problem. I will modify getcompletion() to check for the
'wildoptions' values.
A plugin can save/restore the 'wildoptions' setting if needed to get the
completion
matches with fuzzy matching and without fuzzy matching.

- Yegappan


> Version of Vim
>
> 8.2.4522
> Environment
>
> OS: Windows 11 Pro
> Terminal: Windows Terminal and GUI
> Logs and stack traces
>
> *No response*
>
>
>

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/9986/1074246279@github.com>

Bram Moolenaar

unread,
Mar 22, 2022, 1:11:13 PM3/22/22
to vim/vim, vim-dev ML, Comment

Closed #9986 via e7dd0fa.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.Message ID: <vim/vim/issue/9986/issue_event/6285316643@github.com>

lacygoill

unread,
Mar 22, 2022, 1:47:19 PM3/22/22
to vim/vim, vim-dev ML, Comment

A plugin can save/restore the 'wildoptions' setting if needed to get the
completion
matches with fuzzy matching and without fuzzy matching.

There might be existing scripts which work under the assumption that getcompletion() is not fuzzy. I have a few of them. But if a user with a recent Vim enables the fuzzy algorithm, then these scripts might break.

I wonder whether we should change the default behavior, and ignore the fuzzy algorithm, unless an optional flag is passed. getcompletion() already accepts a third optional argument: filtered. Maybe it could accept a fourth one. Or – to avoid too many optional flags – getcompletion() could accept a dictionary as third argument:

echo getcompletion('ignorecase', 'option', {

    filtered: false,

    fuzzy: false,

})

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: <vim/vim/issues/9986/1075439839@github.com>

Bram Moolenaar

unread,
Mar 22, 2022, 3:50:07 PM3/22/22
to vim...@googlegroups.com, lacygoill

> > A plugin can save/restore the 'wildoptions' setting if needed to get the
> > completion
> > matches with fuzzy matching and without fuzzy matching.
>
> There might be existing scripts which work under the assumption that
> `getcompletion()` is not fuzzy. I have a few of them. But if a user
> with a recent Vim enables the fuzzy algorithm, then these scripts
> might break.
>
> I wonder whether we should change the default behavior, and ignore the
> fuzzy algorithm, unless an optional flag is passed.

Tough call. The question is: do plugins rely on getcompletion() to
return the list like before, or do they rely on getcompletion() to
return what the user would get when doing completion on the command
line?

> getcompletion() already accepts a third optional argument: `filtered`.
> Maybe it could accept a fourth one. Or – to avoid too many optional
> flags – `getcompletion()` could accept a dictionary as third argument:
>
>
> echo getcompletion('ignorecase', 'option', {
> filtered: false,
> fuzzy: false,
> })

If we do want this option, this would be a good way to do it.

--
A vacation is a period of travel during which you find that you
took twice as many clothes and half as much money as you needed.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

Yegappan Lakshmanan

unread,
Mar 22, 2022, 10:21:20 PM3/22/22
to vim_dev, reply+ACY5DGCJ4E5X6OUKPU...@reply.github.com, vim/vim, vim-dev ML, Comment
Hi,

On Tue, Mar 22, 2022 at 10:47 AM lacygoill <vim-dev...@256bit.org> wrote:

A plugin can save/restore the 'wildoptions' setting if needed to get the
completion
matches with fuzzy matching and without fuzzy matching.

There might be existing scripts which work under the assumption that getcompletion() is not fuzzy. I have a few of them. But if a user with a recent Vim enables the fuzzy algorithm, then these scripts might break.

There are many built-in functions which are affected by the different option values.
For example, the 'ignorecase' option affects the match() function and 'wildignorecase'
option affects the getcompletion() function. As Bram mentioned in his reply,
using the 'wildoption' value in getcompletion() will match with what a user will see.
 

I wonder whether we should change the default behavior, and ignore the fuzzy algorithm, unless an optional flag is passed. getcompletion() already accepts a third optional argument: filtered. Maybe it could accept a fourth one. Or – to avoid too many optional flags – getcompletion() could accept a dictionary as third argument:

echo getcompletion('ignorecase', 'option', {

    filtered: false,

    fuzzy: false,

})

In this case, the third argument to getcompletion() will either be a dict or an boolean?

Regards,
Yegappan
 

vim-dev ML

unread,
Mar 22, 2022, 10:23:20 PM3/22/22
to vim/vim, vim-dev ML, Your activity

Hi,

On Tue, Mar 22, 2022 at 10:47 AM lacygoill ***@***.***>

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/9986/1075844422@github.com>

lacygoill

unread,
Mar 23, 2022, 7:10:37 AM3/23/22
to vim/vim, vim-dev ML, Comment

As Bram mentioned in his reply, using the 'wildoption' value in getcompletion() will match with what a user will see.

That's a good point. Indeed the semantics of the function is to match whatever happens on the command-line.

There are many built-in functions which are affected by the different option values. For example, the 'ignorecase' option affects the match() function and 'wildignorecase' option affects the getcompletion() function.

I think I would have preferred for these functions to be immune to user settings, but obviously we can no longer change this.

In this case, the third argument to getcompletion() will either be a dict or an boolean?

Yes, that's what I was thinking. But maybe that's not possible; or maybe it would make the signature of the function too complex (because the type of the last argument would change from bool to any).

I guess we should just wait to see if anybody complains about broken scripts. If nobody does, then there's no reason to change anything.

Anyway, thank you for for the answer.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.Message ID: <vim/vim/issues/9986/1076243258@github.com>

Reply all
Reply to author
Forward
0 new messages