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

Nimsuggest's find definition freezes Emacs #243

Open
dunrix opened this issue Jun 10, 2022 · 1 comment
Open

Nimsuggest's find definition freezes Emacs #243

dunrix opened this issue Jun 10, 2022 · 1 comment

Comments

@dunrix
Copy link

dunrix commented Jun 10, 2022

  • OS name: Linux x86_64

  • Versions
    Emacs: 28.1
    Nim compiler: 1.6.6
    nimsuggest: 1.6.6
    nim-mode: 20211102.917

  • Message related to nim-mode in *Messages* buffer
    nothing - emacs is frozen until quit signal is invoked (with C-g)

  • Steps to reproduce the issue:

  1. Create basic nim project with nimble init.
    Source code of main project's file "playground.nim" follows.
# 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())
  1. Open in Emacs with nim-mode and nimsuggest-mode enabled
  2. Place cursor on some keyword or module-identifier and invoke xref-find-definitions (M-. shortcut by default)
  3. Emacs hangs forever, eating 100% of CPU time. Can be interrupted with (C-g).

When invoked on procs, variables, constants, types - it works as expected, ie. brings in source for that particular identifier.

  • Expected behavior
    Nimsuggest's find definition should reply with something like "no source for selected identifier has been found" instead of ending in non-responsive state.

Command line version of nimsuggest in comparison does work properly, and for keywords & module names instantly replies with '.' (dot symbol), like no definition has been found. Related issue report PMunch/nimlsp#128

@woolsweater
Copy link

woolsweater commented Mar 8, 2023

I have also run into this. I am not familiar with the expected behavior for the IPC with nimsuggest, so I may be wrong, but it looks to me like the while loop inside nimsuggest--call-sync has a slightly flawed termination condition. Here's one possible resolution:

diff --git a/nim-suggest.el b/nim-suggest.el
index 3730ab6..276d66c 100644
--- a/nim-suggest.el
+++ b/nim-suggest.el
@@ -295,11 +295,13 @@ The CALLBACK function is called when it got the response."
      (lambda (candidates)
        (when (eq (current-buffer) buf)
          (setq res (funcall callback candidates)))))
-    (while (and (eq 'trash res) (eq (current-buffer) buf))
-      (if (> (- (time-to-seconds) start) 2)
-          (nim-log "EPC-sync(%s): timeout %d sec" (symbol-name method) 2)
-        (sleep-for 0.03)))
-    (unless (eq 'trash res)
+    (while (and (eq 'trash res)
+                (eq (current-buffer) buf))
+      (if (< (- (time-to-seconds) start) 2)
+          (sleep-for 0.03)
+        (nim-log "EPC-sync(%s): timeout %d sec" (symbol-name method) 2)
+        (setq res 'timeout)))
+    (unless (or (eq 'trash res) (eq 'timeout res))
       res)))
 
 (defun nimsuggest--get-dirty-dir ()

This ensures the loop terminates when the timeout duration is reached.

I can put up a PR if this looks like a reasonable solution to the maintainers.

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

2 participants