Usage with rust-analyzer deletes trailing characters when accepting a completion

[lazkindness]

Make sure you have done the following

• Updated to the latest version of blink.cmp
• Searched for existing issues and documentation (try <C-k> on https://cmp.saghen.dev)

Bug Description

Screen.Recording.2025-05-05.at.11.54.07.AM.mov

When using blink with Rust, I noticed that accepting completions frequently deletes trailing characters. Sometimes it's a lot (like all characters after the completion), and sometimes it's a couple like you can see in the video. Sometimes it doesn't do it at all. I wish I had more information to explain when it does / doesn't happen, but it seems fairly random to me?

Also worth noting, this doesn't happen when I am just scrolling through the list; only when I actually accept a completion from the list. I do not use any kind of auto pair / auto insertion plugin which I thought may have something to do with this.

Relevant configuration

return {
	"saghen/blink.cmp",
	dependencies = {
		"fang2hou/blink-copilot",
		"Kaiser-Yang/blink-cmp-avante",
	},
	version = "1.*",
	opts = {
		keymap = { preset = "super-tab" },
		appearance = {
			nerd_font_variant = "mono",
		},
		completion = {
			menu = { border = "single" },
			documentation = { auto_show = true, window = { border = "single" } },
			trigger = {
				show_in_snippet = false,
			},
			list = {
				selection = { preselect = false },
			},
		},
		signature = { window = { border = "single" } },
		sources = {
			default = { "avante", "copilot", "lsp", "path", "snippets", "buffer" },
			providers = {
				copilot = {
					name = "copilot",
					module = "blink-copilot",
					score_offset = 100,
					async = true,
				},
				avante = {
					module = "blink-cmp-avante",
					name = "Avante",
					opts = {
						icons = false,
					},
				},
			},
		},
	},
}

neovim version

0.11.1

blink.cmp version

1.2

[saghen]

If the user has selected the item with auto_insert enabled, the text might look like [SomeExample], but just before we accept the item, we'll revert the auto_insert, so we'll be left with [SomeEx] (what the user typed before selecting). We then resolve the item, but rust analyzer still thinks the text is [SomeExample] and updates the .textEdit field to include the whole SomeExample, except the text is actually SomeEx now, so it deletes trailing characters.

We haven't marked textEdit as a resolvable field so rust analyzer should not be updating that field. We still accept the updated field for compatibility.

However, this does reveal that the LSP doesn't have an up to date representation of the document when calling resolve, which we should fix on our end.

[nessnoia]

In case anyone encounters this before a fix, I have this in my config to get around this which auto_inserts, matches on prefix instead of full, but replaces everything after the cursor only if it matches the word.

So for example, where | is the cursor:
[Exa|mple] -> searches on Exa
If item is [Exact] -> [Exact|mple]
If item is [Example] -> [Example|]

	sources = {
		transform_items = function(ctx, items)
			local cursor_col = ctx.cursor[2]

			for _, item in ipairs(items) do
				if item.textEdit and item.textEdit.insert then
					local s = ctx.bounds.start_col
					local e = s + ctx.bounds.length - 1
					local typed_fragment = ctx.line:sub(s, e)

					-- Plus 2 for lua 1 based indexing, and then for getting the position after the letter the
					-- cursor is technically on (I think that's why.. but determined this by testing prints)
					local cursor_idx = cursor_col + 2 - s
					local word_after_cursor = typed_fragment:sub(cursor_idx)

					-- If the text after the prefix match matches the insertion item, replace it, otherwise insert
					-- before the item.
					if item.textEdit.newText:match(word_after_cursor) then
						local start_replace = item.textEdit.replace.start.character
						item.textEdit.replace["end"].character = start_replace + #typed_fragment
						item.textEdit.range = item.textEdit.replace
					end
				end
			end
			return items
		end,
	},