cmp-cmdline causes Neovim to freeze when using ! in command mode

[theSprog]

I encountered an issue described in title with the cmp-cmdline plugin when using Neovim. The problem occurs when I attempt to execute a shell command using ! in command mode.

I have tried disabling the cmp-cmdline plugin, and the issue disappears when the plugin is disabled. This leads me to believe that the problem lies within the cmp-cmdline plugin.

Steps to reproduce:

1. Install and configure the cmp-cmdline plugin in Neovim.

2. Enter command mode by pressing :.

3. Type r followed by a space.

4. Type ! to indicate a shell command.

5. Attempt to type the shell command (e.g., ls). that I want to type is

   r !ls
   

Expected behavior:
Neovim should allow me to type the shell command without any freezing or long processing times. The command should be executed immediately when I press Enter.

Actual behavior:
After typing !, Neovim freezes and becomes unresponsive. It appears to be stuck in a long processing logic. After waiting for a few minutes, Neovim eventually reads the contents of the ls command, but the freezing and long processing time are unacceptable.

Additional information:

• Neovim version: 0.9.5

• cmp-cmdline version: These is no release published in the cmp-cmdline and I’m using lazy.nvim to install it

• Operating system: WSL + arch

• options:

  cmp.setup.cmdline(":", {
          mapping = cmp.mapping.preset.cmdline(),
          sources = cmp.config.sources({
                  { name = "path" },
              }, {
                  {
                      name = "cmdline",
                      option = {
                          ignore_cmds = { "Man", "!" },
                      },
                  },
              }),
      })

[theSprog]

I checked the source code and I don't know if there is a problem here.

  if vim.tbl_contains(option.ignore_cmds, parsed.cmd) then
    return {}
  end

  -- Cleanup modifiers.
  -- We can just remove modifiers because modifiers is always separated by space.
  if arglead ~= cmdline then
    while true do
      local s, e = MODIFIER_REGEX:match_str(cmdline)
      if s == nil then
        break
      end
      cmdline = string.sub(cmdline, e + 1)
    end

Here vim.tbl_contains(option.ignore_cmds, parsed.cmd) does not seem to filter out strings like 'r !ls', so it is not stopped by return {}, and there is a while true after it, so neovim seems to be stuck

[dhnam]

+1 for this. This is why ! is ignored by default (as it takes really long time) I believe.

#109 (I opened the issue, btw) can be handeled here, as it is caused by same '! is not ignored by cmp-cmdline when it is not follows : directly'.

[sybereal]

I believe I have run into a similar issue.

I added terminal to the list of ignored commands for the same reason as ! is there, because trying to complete the 11k+ executables on my PATH (according to fzf) would freeze Neovim for over a minute, if not more.

However, I noticed that, when I chain commands using |, the ignore does not seem to apply. This is unfortunate, as I often do :split | terminal run-something to start a process in a new terminal split.

For now, I'll see if I can work around this by adding a custom command that wraps this split | terminal workflow and then put that on my ignore list.

[mau-mauricelim]

I have the same issue with :w ! and :r !

[Alfamari]

Not a great workaround, but if you add the full names for the command prefix you are trying to ignore with the ! it will work. So ignore_cmds = { 'Man', '!', 'read', 'write' } will prevent the hang on :r!, :r !, and :w !. Unfortunately, this comes with a ton of false positives, so there won't be any completions for any other command that starts with w or r until you keep typing and reach a letter that breaks the sequence of those commands. Like ru or wi.

Dunno if it's possible to improve this by adding another keybind that would utilize a different ignore list or 'ignore' the ignore list, so as to choose when you want to disable completions for :r! but allow completions for :r. But for me, I only need to fix the read until I wait for a fix.

I was also unable to adopt this older solution to the current issue:
#24 (comment)

[asampley]

Not a great workaround, but if you add the full names for the command prefix you are trying to ignore with the ! it will work. So ignore_cmds = { 'Man', '!', 'read', 'write' } will prevent the hang on :r!, :r !, and :w !.

I have a solution that shouldn't require an ignores, that I believe is flexible enough to extend in case it still hangs for you, you can delay how many characters it waits for until it does work for you.

The key insight I think I was missing for a while, is either trigger_characters or keyword_pattern trigger completion. One of the default trigger characters was ' '. Removing all trigger characters solves a lot of problems people had with e.g. terminal.

After a single character, I found the list was short enough in WSL to be responsive. If it isn't for you, it's possible to change the \{1,\} in the final part of the regex to a length specific to keywords after the first command. The regex is a bit longer because I wanted the initial command to complete immediately, while I could set the length of future keyword completions.

This is my definition of the cmdline source.

{
	name = 'cmdline',
	trigger_characters = {},
	keyword_pattern = [==[\(^[^![:blank:]]*\|[^![:blank:]]\{1,}\)]==],
	option = {
		ignore_cmds = {},
	}
}

Why it works: completion is triggered either at the start, or after 1 or more characters that aren't [:blank:] or !. The 1 can be changed to 2 if you still find it too slow.

Actually, with a default keyword_length of 1, the regex can be a lot shorter if 1 character works for you, ([==[[^![:blank:]]*]==]).

For now, I'll see if I can work around this by adding a custom command that wraps this split | terminal workflow and then put that on my ignore list.

Because it delays completion rather than ignores it, my solution also worked for me in this case, no custom command necessary. If it's still too slow, again, changing the 1 to a 2 may solve it for you, though cut down more immediate completions.

The ideal solution plugin code-wise might be to add an option controlling a length that external commands will be mixed into the completions, as it is specifically places where external commands pop up that seem to be causing all the problems.

[Holi0317]

Probably duplicate of #85. Culprit is vim.fn.getcompletion is blocking and cost a lot of time.

Try running this command and see how long it takes.

:lua = vim.fn.getcompletion("!", "cmdline")

My guess is under WSL2 (don't have this issue on my mac, only WSL laptop got it), some entries in $PATH are pointing to /mnt/c/... and filesystem performance under /mnt is really bad.

[sybereal]

I'm confused as to why Nvim takes that long, though. I am a WSL2 user as well, yes, but I have other snippets that scan my entire $PATH, and they don't freeze for minutes at a time.

This snippet, which I occasionally use to find executables that I don't remember the exact name of, takes less than 4 seconds to scan everything (16.3k hits total), including several /mnt/c/ subdirectories: fd --type x --max-depth 1 --hidden --no-ignore --follow --print0 . $path. And it does so while using exactly one core of CPU on a 16-thread machine.