Inserts duplicate text on receiving an `additionalTextEdit`

[stefanvanburen]

Hi,

I'm working on adding completion to the Buf Language Server, and currently adding support for sending an additionalTextEdit to complete a final ; at the end of a line in certain completion cases.

It looks like asyncomplete-lsp.vim is adding the additionalTextEdit correctly, but then seemingly duplicates the entire line after the text edit. e.g., I start with:

import "
//      ^ cursor is here; autocomplete is activated

I want:

import "google/protobuf/type.proto";

I get:

import "google/protobuf/type.proto";import "google/protobuf/type.proto"

My .vimrc is just:

call plug#begin()
" LSP plugins
Plug 'prabirshrestha/vim-lsp'
Plug 'mattn/vim-lsp-settings'

" Autocomplete plugins
Plug 'prabirshrestha/asyncomplete.vim'
Plug 'prabirshrestha/asyncomplete-lsp.vim'
call plug#end()

Then I use <c-n> to move through completion suggestions and <c-y> to apply it.

Both neovim's mini.complete and nvim-cmp seem to handle this case correctly, in case that helps in tracking down the issue. Happy to provide any other details!

[mattn]

Could you please try :echo b:asyncomplete_refresh_pattern (might be an error)

[stefanvanburen]

Could you please try :echo b:asyncomplete_refresh_pattern (might be an error)

E121: Undefined variable: b:asyncomplete_refresh_pattern

Haven't set it on my end, so seems expected.

[mattn]

Typically, asyncomplete-lsp inserts completion text after moving the cursor back by the length of the specific keyword. This movement is often to the position matched by \k+ before the cursor. If you are experiencing this issue despite having a correct buf language server, you may have modified the iskeyword setting.

[stefanvanburen]

may have modified the iskeyword setting.

I don't think so; it's not changed in my .vimrc (shown above) and echo &iskeyword is just @,48-57,_,192-255, which looks like the default for iskeyword on macOS.

[stefanvanburen]

I don't fully understand either's code, but it looks like in vim-lsp, the additionalTextEdit is applied before the textEdit(s) themselves:

https://github.com/prabirshrestha/vim-lsp/blob/04ef607075184e7b8481245a40a9010368511e98/autoload/lsp/ui/vim/completion.vim#L103-L109

Meanwhile, mini.completion applies the additionalTextEdit afterwards:

https://github.com/nvim-mini/mini.nvim/blob/d1a91582bf2d16026ae84292874c70fb2d0ffe42/lua/mini/completion.lua#L1343-L1344

Maybe applying the additionalTextEdit before the edit is causing some state tracking to be wrong?

[mattn]

I want to reproduce this but:

[33mWARN[0m	could not find module	{"file":"C:\\dev\\protoc-sandbox\\foo.proto"}
[33mWARN[0m	notify returned	{"method":"$/progress"}
[31mERROR[0m	failed to get importable files	{"file":"C:\\dev\\protoc-sandbox\\foo.proto"}
[33mWARN[0m	notify returned	{"method":"$/progress"}
[34mINFO[0m	parsing IR for file	{"uri":"file:///C:/dev/protoc-sandbox/foo.proto","version":1}
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x28 pc=0x7ff7afa9b380]

goroutine 52 [running]:
github.com/bufbuild/buf/private/buf/buflsp.(*file).RefreshIR(0xc0006f7e68, {0x7ff7b0564520, 0xc00061c4d0})
	C:/Users/mattn/AppData/Local/vim-lsp-settings/servers/buf/pkg/mod/github.com/bufbuild/[email protected]/private/buf/buflsp/file.go:446 +0x1c0
github.com/bufbuild/buf/private/buf/buflsp.(*file).Refresh(0xc0006f7e68, {0x7ff7b0564520, 0xc00061c4d0})
	C:/Users/mattn/AppData/Local/vim-lsp-settings/servers/buf/pkg/mod/github.com/bufbuild/[email protected]/private/buf/buflsp/file.go:295 +0x119
github.com/bufbuild/buf/private/buf/buflsp.(*server).DidOpen(0xc000730dc8?, {0x7ff7b0564520, 0xc00061c4d0}, 0xc000691700)
	C:/Users/mattn/AppData/Local/vim-lsp-settings/servers/buf/pkg/mod/github.com/bufbuild/[email protected]/private/buf/buflsp/server.go:227 +0x85
go.lsp.dev/protocol.serverDispatch({0x7ff7b0564520, 0xc00061c4d0}, {0x7ff7b05ca790, 0xc00012a378}, 0xc0004f9f38, {0x20bf18e40e8, 0xc00049cc30})
	C:/Users/mattn/AppData/Local/vim-lsp-settings/servers/buf/pkg/mod/go.lsp.dev/[email protected]/server.go:314 +0x22ee
github.com/bufbuild/buf/private/buf/buflsp.(*lsp).newHandler.ServerHandler.func2({0x7ff7b0564520, 0xc00061c4d0}, 0xc0004f9f38, {0x20bf18e40e8, 0xc00049cc30})
	C:/Users/mattn/AppData/Local/vim-lsp-settings/servers/buf/pkg/mod/go.lsp.dev/[email protected]/server.go:36 +0x7d
github.com/bufbuild/buf/private/buf/buflsp.(*lsp).newHandler.func1({0x7ff7b0564520, 0xc00061c4d0}, 0xc00030a7c8, {0x20bf18e40e8, 0xc00049cc30})
	C:/Users/mattn/AppData/Local/vim-lsp-settings/servers/buf/pkg/mod/github.com/bufbuild/[email protected]/private/buf/buflsp/buflsp.go:145 +0x43d
github.com/bufbuild/buf/private/buf/buflsp.(*lsp).newHandler.AsyncHandler.func3.2()
	C:/Users/mattn/AppData/Local/vim-lsp-settings/servers/buf/pkg/mod/go.lsp.dev/[email protected]/handler.go:114 +0x76
created by github.com/bufbuild/buf/private/buf/buflsp.(*lsp).newHandler.AsyncHandler.func3 in goroutine 15
	C:/Users/mattn/AppData/Local/vim-lsp-settings/servers/buf/pkg/mod/go.lsp.dev/[email protected]/handler.go:112 +0x165

[stefanvanburen]

hey @mattn, thanks for taking a look and the patience.

[email protected]

I think you have the existing release of buf, but that PR only landed on main; may need to install from there directly:

$ go install github.com/bufbuild/buf/cmd/buf@main