Response timeout when description requested on a keyword

[dunrix]

• problem description
  When in Nim's source code contextual help is invoked on a keyword like when, return, proc etc, nimlsp/nimsuggest stops responding until editor's timeout expires (12 seconds in my case).

• logged information of the event
  lsp-request: Timeout while waiting for response. Method: textDocument/hover

• testing environment
  emacs 28.1, lsp-mode-20220605, nimlsp v0.4.1, nim 1.6.6, OS Linux x86_64

• expected behavior
  Reply immediately either with a appropriate description or info about there is no description available.

When the contextual help is invoked on other tokens like variables, types, literals, procedures - nimlsp responds instantly with a correct description.

[PMunch]

Hmm, this sounds like a nimsuggest issue. I guess the way forward would be to test with just nimsuggest and see if that has the same issue.

[dunrix]

Hmm, this sounds like a nimsuggest issue. I guess the way forward would be to test with just nimsuggest and see if that has the same issue.

Not sure if nimsuggest is to be blamed.
When tested with nimsuggest alone on following basic source code in playground.nim file:

# This is just an example to get you started. A typical hybrid package
# uses this file as the main entry point of the application.

import playgroundpkg/submodule

when isMainModule:
  echo(submodule.getWelcomeMessage())

with nimsuggest --stdin --debug src/playground.nim

then invoking def command on keywords or module-name, like

# find definition of `when`
> def 6:0
.
# find definition of `submodule`
> def 7:7
.
# find definition of `isMainModule`
> def 6:5
.def	skConst	system.isMainModule	bool	/home/dunrix/.choosenim/toolchains/nim-1.6.6/lib/system.nim	1099	2	""	100

Reply of nimsuggest to definition of a keyword or module-identifer token with . (dot, codepoint 46) is instant.
Maybe nimlsp does not handle this case correctly?

[PMunch]

Thanks for the reproduction sample, I think I found the issue. Due to a recent refactor the code path to send the reply was only inside the block where it had definitions. I think this should be fixed in cf07e22, could you check it out?

[dunrix]

Thank you!

It seems issue with xref-find-definitions command has been fixed.

Unfortunately the issue still persists for lsp-describe-thing-at-point. When invoked on a keyword like when or import, it stops responding until timeout expires.

Any chance for a similar quick fix?

[PMunch]

Do you know which LSP commands are called by those two? If so I can fix it easily

[dunrix]

Do you know which LSP commands are called by those two? If so I can fix it easily

Not sure about that, I'm not an elisp guy.

From the source of that function, it seems like `"textDocument/hover" command and "hover-contents"(?) are invoked:

(defun lsp-describe-thing-at-point ()
  "Display the type signature and documentation of the thing at
point."
  (interactive)
  (let ((contents (-some->> (lsp--text-document-position-params)
                    (lsp--make-request "textDocument/hover")
                    (lsp--send-request)
                    (lsp:hover-contents))))
    (if (and contents (not (equal contents "")))
        (let ((lsp-help-buf-name "*lsp-help*"))
          (with-current-buffer (get-buffer-create lsp-help-buf-name)
            (with-help-window lsp-help-buf-name
              (insert (string-trim-right (lsp--render-on-hover-content contents t))))))
      (lsp--info "No content at point."))))

from lsp-protocol.el

 (Hover (:contents) (:range))
 (HoverParams (:textDocument :position) (:uri))

Not sure how the latter is exactly translated to a LSP request.

When no definition can be retrieved, an empty/nil response is to be expected, which would lead in "No content at point." editor's reply.

[dunrix]

The issue still persists, however I did solved it by replacing with alternate server: nimlangserver, which does not suffer described behavior. It may be related to a different approach how nimsuggest is handled.

Leaving it as a notice here for possible other affected users, just for the sake of reference.

[PMunch]

I've noticed hover being a bit broken myself lately. It seems like something in the library version of nimsuggest is causing issues and I'm looking into it.

[bung87]

It probably goes to https://github.com/nim-lang/Nim/blob/d372ad3ee6563cff2c086e774f1e00b091b79373/compiler/suggest.nim#L502

I've debugged into this , replace it with discard while hovering keyword it doesn't crash but still pending the request. as nim keyword it should response empty