Merged #3617 breaks UltiSnips placeholder mechanism

[dunric]

It seems merged PR #3617 breaks code completion for function placeholders.

I had to roll back to preceding commit to make it work again.

After the PR, using code completion at function's argument placeholder (provided by UltiSnips), a selected identifier is inserted including its previously typed-in prefix.

For example, create a variable sample := []int{1,2,3} . Then later attempt to put it in a function argument using code completion, at a placeholder position invoke omni-completion menu, type leading three chars sam and select sample identifier - results in following

fmt.Println(samsample)
            ^^^

[Billie Cleek]

I'm not able to replicate any changes in behavior between #3617 and master before it was merged. Perhaps your 'completeopt' setting may be useful. What do you have for it?

[Tim Esselens]

I'm seeing this as well, bisected to commit 3c223ad

might it be an off-by-one in autoload/go/lsp/lsp.vim:12 ?
return [l:line - 1, s:character(l:line, l:col-1)] vs return [l:line - 1, s:character(l:line, l:col)]

I rolled back because my ultisnips contains a "macro" for printf

global !p
  def echo_vals(t, placeholder="%+v"):
     return ', '.join(["%s: %s" % (a.strip(), placeholder) for a in
        t[1].split(',') if len(a.strip())])
endglobal

which is then used inside the snippet:

  snippet p "printf" b
  fmt.Printf("${2}`!p snip.rv = echo_vals(t)`\n", ${1})
  endsnippet

I could not complete at the placeholder anymore, all context seems to be lost.
I've only looked at it briefly but from the GoLspDebugBrowser output it seems that there is some kind of line/col mismatch as the debugger showed something about the line not having so many cols. First I assumed it was a line number off by one. Didn't investigate fully at that time.

completeopt=menuone,noinsert,noselect

[Billie Cleek]

Thank you, @timesselens. I can duplicate this now and see that it was working prior to #3617.