Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Response timeout when description requested on a keyword #128

Open
dunrix opened this issue Jun 7, 2022 · 9 comments
Open

Response timeout when description requested on a keyword #128

dunrix opened this issue Jun 7, 2022 · 9 comments

Comments

@dunrix
Copy link

dunrix commented Jun 7, 2022

  • 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
Copy link
Owner

PMunch commented Jun 7, 2022

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
Copy link
Author

dunrix commented Jun 9, 2022

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
Copy link
Owner

PMunch commented Jun 10, 2022

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
Copy link
Author

dunrix commented Jun 11, 2022

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
Copy link
Owner

PMunch commented Jun 11, 2022

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

@dunrix
Copy link
Author

dunrix commented Jun 12, 2022

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
Copy link
Author

dunrix commented Jan 30, 2023

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
Copy link
Owner

PMunch commented Jan 30, 2023

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
Copy link
Contributor

bung87 commented May 23, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants