bug: plugin interferes with commandline completion

[Quitlox]

• nvim --version: v0.10.3
• Operating system/version: 6.12.7-arch1-1

Describe the bug
After debugging my configuration I found that nvim-hlslens interferes with the completion popup opened by blink.cmp. Specifically, it appears that nvim-hlslens causes the completion popup to be dismissed after hitting the <Tab> key twice in commandline mode.

Since "blink.cmp" works fine with every other plugin in my configuration, my suspicion is that "hlslens" has some unexpected behaviour.

Does nvim-hlslens modify the commandline in anyway?

To Reproduce using nvim -u mini.lua

Example:
cat mini.lua

-- <insert rocks.nvim bootstrap code (see end of issue)> or install the plugins using other means (latest git revision for both).

require("blink-cmp").setup({
	keymap = {
		cmdline = {
			["<Tab>"] = { "select_next", "fallback" },
			["<S-Tab>"] = { "select_prev", "fallback" },
		},
	},
	completion = {
		list = {
			selection = "auto_insert",
		},
	},
})

require("hlslens").setup()

1. Open neovim with minimal configuration
2. Start typing a command, e.g. ":ro"
3. Press <Tab> at least twice

Expected behavior
The completion popup is dismissed after pressing the second <Tab> and it shouldn't.

Screenshots

Additional Context

rocks.nvim bootstrap snippet

do
	-- Specifies where to install/use rocks.nvim
	local install_location = vim.fs.joinpath(vim.fn.stdpath("data"), "rocks")

	-- Set up configuration options related to rocks.nvim (recommended to leave as default)
	local rocks_config = {
		rocks_path = vim.fs.normalize(install_location),
	}

	vim.g.rocks_nvim = rocks_config

	-- Configure the package path (so that plugin code can be found)
	local luarocks_path = {
		vim.fs.joinpath(rocks_config.rocks_path, "share", "lua", "5.1", "?.lua"),
		vim.fs.joinpath(rocks_config.rocks_path, "share", "lua", "5.1", "?", "init.lua"),
	}
	package.path = package.path .. ";" .. table.concat(luarocks_path, ";")

	-- Configure the C path (so that e.g. tree-sitter parsers can be found)
	local luarocks_cpath = {
		vim.fs.joinpath(rocks_config.rocks_path, "lib", "lua", "5.1", "?.so"),
		vim.fs.joinpath(rocks_config.rocks_path, "lib64", "lua", "5.1", "?.so"),
	}
	package.cpath = package.cpath .. ";" .. table.concat(luarocks_cpath, ";")

	-- Add rocks.nvim to the runtimepath
	vim.opt.runtimepath:append(
		vim.fs.joinpath(rocks_config.rocks_path, "lib", "luarocks", "rocks-5.1", "rocks.nvim", "*")
	)
end

-- If rocks.nvim is not installed then install it!
if not pcall(require, "rocks") then
	local rocks_location = vim.fs.joinpath(vim.fn.stdpath("cache"), "rocks.nvim")

	if not vim.uv.fs_stat(rocks_location) then
		-- Pull down rocks.nvim
		vim.fn.system({
			"git",
			"clone",
			"--filter=blob:none",
			"https://github.com/nvim-neorocks/rocks.nvim",
			rocks_location,
		})
	end

	-- If the clone was successful then source the bootstrapping script
	assert(vim.v.shell_error == 0, "rocks.nvim installation failed. Try exiting and re-entering Neovim!")

	vim.cmd.source(vim.fs.joinpath(rocks_location, "bootstrap.lua"))

	vim.fn.delete(rocks_location, "rf")
end

Thanks a lot for the work on this plugin, I really enjoy using it.

[kevinhwang91]

Not a blink.cmp user, maybe the issue is caused by

nvim-hlslens/lua/hlslens/cmdline/init.lua

Lines 210 to 213 in 0bd7ddb

	self.searching = self.parser:doParse()
	if not self.searching then
	return
	end

, need to debug by a blink.cmp user.

[Quitlox]

Not a blink.cmp user, maybe the issue is caused by

nvim-hlslens/lua/hlslens/cmdline/init.lua

Lines 210 to 213 in 0bd7ddb

	self.searching = self.parser:doParse()
	if not self.searching then
	return
	end

, need to debug by a blink.cmp user.

Thanks for the hint! I'll make an attempt at debugging this myself this week, but any hints as to why this may happen are very welcome.

[kevinhwang91]

Not a blink.cmp user, maybe the issue is caused by

nvim-hlslens/lua/hlslens/cmdline/init.lua

Lines 210 to 213 in 0bd7ddb

	self.searching = self.parser:doParse()
	if not self.searching then
	return
	end

, need to debug by a blink.cmp user.

Thanks for the hint! I'll make an attempt at debugging this myself this week, but any hints as to why this may happen are very welcome.

I will