mini.completion: Rapidly remove and typing characters can slow down typing

[mortezadadgar]

Contributing guidelines

• I have read CONTRIBUTING.md
• I have read CODE_OF_CONDUCT.md
• I have updated 'mini.nvim' to latest version

Module(s)

mini.completion

Description

hey,
while configing mini.files found out that mini.completion could makes text lags to appear on screen, I recorded a video to show how easily it can be reproduced

out_new.mp4

Neovim version

0.9.5

Steps to reproduce

1. open a file like this:

return {
	"echasnovski/mini.files",
	config = function()
		require("mini.files").setup()
		vim.keymap.set("n", "-", "<cmd>=MiniFiles.open()<CR>")

		vim.api.nvim_create_autocmd("FileType", {
			pattern = "minifiles",
			},
	end,
}

2. move to pattern line and try to rapidly write callback and remove it letter by letter

Expected behavior

Having smooth typing experience

Actual behavior

it's visible in recorded video.

[echasnovski]

Unfortunately, I can not reproduce this. The reproduction steps are not complete: in video you have autocompletion from 'lua/autocmd.lua' file with unknown content.

I'd ask to make it indeed reproducible with only 'mini.completion' enabled and some known text in buffers opened.

---

Here is what I have:

completion-lag-norepro.mp4

---

That said, if this comes from fallback built-in completion, it might have this effect if there is some buffer with lots of text to scan (like somewhere around 10000 lines). But it can be not this case, of course.

[mortezadadgar]

That said, if this comes from fallback built-in completion, it might have this effect if there is some buffer with lots of text to scan (like somewhere around 10000 lines). But it can be not this case, of course.

it's only a autocmd config with only 49 lines of code:

local group = vim.api.nvim_create_augroup("UserGroup", {})

vim.api.nvim_create_autocmd("TextYankPost", {
	desc = "Highlight on yank",
	group = group,
	pattern = "*",
	callback = function()
		vim.highlight.on_yank()
	end,
})

vim.api.nvim_create_autocmd("BufEnter", {
	desc = "Disable auto formatting on newline",
	group = group,
	callback = function()
		vim.opt.formatoptions:remove { "r", "o" }
	end,
})

vim.api.nvim_create_autocmd("VimResized", {
	desc = "Resize splits if window got resized",
	group = group,
	command = "tabdo wincmd =",
})

vim.api.nvim_create_autocmd("QuickFixCmdPost", {
	desc = "Show quickfix window automatically",
	group = group,
	pattern = "[^l]*",
	command = "cwindow",
	nested = true,
})

vim.api.nvim_create_autocmd("BufReadPost", {
	desc = "Go to last loc when opening a buffer",
	group = group,
	callback = function(event)
		local buf = event.buf
		local exclude = { "gitcommit", "gitrebase" }
		if vim.tbl_contains(exclude, vim.bo[buf].filetype) then
			return
		end
		local mark = vim.api.nvim_buf_get_mark(buf, '"')
		local lcount = vim.api.nvim_buf_line_count(buf)
		if mark[1] > 0 and mark[1] <= lcount then
			pcall(vim.api.nvim_win_set_cursor, 0, mark)
		end
	end,
})

maybe there's something here that makes it hard to parse

it's reproducible on this minimal config:

local lazypath = vim.fn.stdpath "data" .. "/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
	vim.fn.system {
		"git",
		"clone",
		"--filter=blob:none",
		"https://github.com/folke/lazy.nvim.git",
		"--branch=stable",
		lazypath,
	}
end
vim.opt.rtp:prepend(lazypath)

require("lazy").setup {
	{
		"neovim/nvim-lspconfig",
		config = function()
			local capabilities = vim.lsp.protocol.make_client_capabilities()
			capabilities.workspace.didChangeWatchedFiles.dynamicRegistration = true
			capabilities.textDocument.completion.completionItem.snippetSupport = true
			local settings = {
				lua_ls = {
					Lua = {
						telemetry = {
							enable = false,
						},
						workspace = {
							checkThirdParty = false,
							library = vim.api.nvim_get_runtime_file("", true),
						},
					},
				},
			}

			require("lspconfig")["lua_ls"].setup {
				capabilities = capabilities,
				settings = settings["lua_ls"],
			}
		end,
	},

	{
		"echasnovski/mini.completion",
		opts = {
			lsp_completion = {
				source_func = "omnifunc",
			},
			fallback_action = "<C-n>",
		},
	},
}

One thing I like to mention even on recorded screen you send removing character is not quite smooth it's clearly is lagging in comparison to not having a auto completion.

[echasnovski]

it's reproducible on this minimal config:

Yes, I can reproduce it with this config. This probably comes from combination of LSP and fallback action. I'll look into it, but I'd guess that this is just the way this is going to work.

One thing I like to mention even on recorded screen you send removing character is not quite smooth it's clearly is lagging in comparison to not having a auto completion.

It is as smooth as without 'mini.completion'. What might be perceived as lag is either not consistent key strokes or recording artifacts.

[echasnovski]

So... I've done some testing. My current hypothesis is that this is a result of a default fallback action kicking in. The only way I can reproduce this is as following:

• Type ca fast.
• Make delay just over 100 ms, which is the default of config.delay.completion.
• Type ll fast.

With these steps I can see similar drawing issues as in original video. I think I did not see it initially because I typed too fast thinking it was a performance issue.

@mortezadadgar, I would like to ask you to confirm the hypothesis (at least to a certain degree) by setting fallback_action = function() end instead of "<C-n>" and trying to reproduce same drawing issues. With this, I could not reproduce.

---

If no fallback action resolves the issues, then I am afraid nothing can be done here. Built-in completion is synchronous by its implementation and there is no reasonable way to go around that.

[mortezadadgar]

Disabling fallback action indeed is solving the issue but that's where the callback is coming from, if bottleneck is coming from core so I think it's unrelated to this plugin and this can be closed.
Thanks for investigating the issue.

[echasnovski]

Disabling fallback action indeed is solving the issue but that's where the callback is coming from ...

Yeah, true. It could still have been an issue with something 'mini.completion' does explicitly (state tracking, etc.).

Another advice might be to increase or decrease the config.delay.completion setting. If you experience this issue often, it might so happen that the typing speed doesn't play well with default 100 ms. One case why it was visible in call is because it is hard to type smoothly on regular QWERTY keyboard.

Closing as (there seems like) nothing can be done due to synchronous nature of default fallback.