[Spacemacs.develop] [lsp-go] No autocompletion with lsp-go, autocompletion OK in plain go-mode

[stradicat]

Autocomplete using lsp-go is not working: tab-complete mostly yields a [No matches] message on the modeline gutter, or a slow, garbled autocompletion.

However, editing go files using regular, plain go-mode works OK with autocompletion, and much faster at it.

To Reproduce
In Spacemacs develop, enable the golayer with the following options:

(go :variables
         go-backend 'lsp)

Expected behavior
Open any project's main.go file, try to add something, like

func test(w http.ResponseWriter, r *http.Request){
        fmt.Fprintf(w, "This is a test")
}

and try using tab to autocomplete parts of the code.
Autocompleting

http

at ht will yield a hhttpt pattern instead of the expected http.
I reported a similar problem last year, and the problem went away after some work on gopls by its maintainers, but this time the problem is "back & reloaded".

Longer expected patterns will be ignored under a [No matches] message.

Which Language Server did you use
lsp-go

(all go dependencies listed on the Spacemacs develop readme have been properly installed and updated at the time of this bug report)

OS
elementaryOS 5.0 / Ubuntu 18.04

Error callstack
Using the example above, when tab-autocompleting at func test(w http.Respon (for http.ResponseWriter, line 25 of my test code), the following backtrace is shown by Emacs:

Debugger entered--Lisp error: (args-out-of-range 0 0)
  text-properties-at(0 nil)
  #f(compiled-function (candidate status) #<bytecode 0x1dfd0ad>)(nil finished)
  completion--done(nil finished)
  #f(compiled-function () #<bytecode 0x4346dfd>)()
  helm--completion-in-region(completion--in-region #<marker at 936 in main.go> 942 #f(compiled-function (probe pred action) #<bytecode 0x4d907ad>) nil)
  apply(helm--completion-in-region completion--in-region (#<marker at 936 in main.go> 942 #f(compiled-function (probe pred action) #<bytecode 0x4d907ad>) nil))
  #f(advice-wrapper :around completion--in-region helm--completion-in-region)(#<marker at 936 in main.go> 942 #f(compiled-function (probe pred action) #<bytecode 0x4d907ad>) nil)
  completion-in-region(#<marker at 936 in main.go> 942 #f(compiled-function (probe pred action) #<bytecode 0x4d907ad>) nil)
  #f(compiled-function () (interactive nil) #<bytecode 0x24b233>)()
  apply(#f(compiled-function () (interactive nil) #<bytecode 0x24b233>) nil)
  completion-at-point()
  indent-for-tab-command(nil)
  funcall-interactively(indent-for-tab-command nil)
  call-interactively(indent-for-tab-command nil nil)
  command-execute(indent-for-tab-command)

compressed lsp log

Let me know what else I can provide to debug this further.

[yyoncho]

Update to latest helm version.

[stradicat]

I just upgraded to helm-20200123.1412, and the problem persists.

[yyoncho]

@DennisMayr can make sure you have this: emacs-helm/helm#2265 ?

[stradicat]

Will check again and report back during the day.

[stradicat]

Just upgraded to helm-20200124.1937 (assuming it contains the merged change); the problem persists when using gopls ☹️
It's the only language server that's showing problems, all other modes using lsp are working perfectly.

[yyoncho]

  (with-eval-after-load 'lsp-mode
    (define-key lsp-mode-map (kbd "TAB") #'company-indent-or-complete-common)

I think that the lines listed above will workaround your issue. I will investigate - but based on the callstack seems like helm is miscalculating the candidate. (cc @thierryvolpiatto ).

[zot]

@DennisMayr is your go.mod file not at the project root, by any chance? I found that this confuses gopls and renders it inoperable for the project.

If this is the case, you can use M-x lsp-workspace-folders-remove to remove the current project from GOLSP's list. Then run M-x lsp and use I and pick the folder that contains your go.mod file. Don't use i, which has a bad default choice.

I just filed this bug report after I figured out how to solve the problem: #1978

[stradicat]

That does alleviate the problem cause. Closing.

[zot]

Unfortunately my suggestion was rejected on the grounds that it was out of scope but over time I expect more and more people to file issues about this since the projectile root cannot be the LSP root in many cases of multilanguage projects.