syl20bnr / spacemacs

A community-driven Emacs distribution - The best editor is neither Emacs nor Vim, it's Emacs *and* Vim!
http://spacemacs.org
GNU General Public License v3.0
23.68k stars 4.89k forks source link

Clojure Layer - SPC m h bindings not working correctly for CLI based projects #14057

Closed theophilusx closed 3 years ago

theophilusx commented 3 years ago

Description :octocat:

Clojure layer. Appears to be an issue with documentation lookup bindings

SPC m h c and SPC m h d and SPC m h a don't work. With SPC m h d you get the error wrong-type-argument char-or-string-p nil and the below backtrace

With other actions, such as apropos (SPC m h a) and cider doc (SPC m h h) you get an error saying the symbol could not be resolved, even for core functions (and despite the fact that when using cider-doc, it shows the symbol signature (qualified with ns) in the mode-line).

Also note that when entering these bindings, normally, the symbol under point would be offered as a default. No default is offered. You have to type in the value you want to lookup.

Reproduction guide :beetle:

this will generate the error.

Observed behaviour: :eyes: :broken_heart: Executing cider-clojuredocs lookup fails with a wrong type argument error. For other documentation lookup bindings, like cider-apropos or cide-doc, you get an error stating the symbol could not be found even though the symbol is a core function and even though the mode line displays the fully qualified (i.e. with clojure.core/ namespace).

Expected behaviour: :heart: :smile: When using one of the documentation lookup functions, the input should default to whatever the current symbol is under point. This is not occuring.

For core functions and variables, the lookup should return the corresponding documentation in a cider document view buffer.

Note that running vanilla Emacs -Q and loading the clojure, cider and helm-clojure packages these functions work fine. Seems to be a spcemacs specific issue.

System Info :computer:

Backtrace :paw_prints:

Debugger entered--Lisp error: (wrong-type-argument char-or-string-p nil)
  cider-clojuredocs--content(nil)
  cider-clojuredocs-lookup("case")
  cider-try-symbol-at-point("ClojureDocs doc for" cider-clojuredocs-lookup)
  cider-clojuredocs(nil)
  funcall-interactively(cider-clojuredocs nil)
  call-interactively(cider-clojuredocs nil nil)
  command-execute(cider-clojuredocs)
rakyi commented 3 years ago

I'm unable to reproduce. Cider version: CIDER 1.0.0snapshot (package: 20201018.1453)

System Info :computer:

theophilusx commented 3 years ago

Did a bit more digging. It seems this is only an issue with CLI based projects. Does not occur with a lein based project. Here is what I tried

lein new app doctest

open src/doctest/core.clj, start a repl with cider-jack-in-clj, place cursor on println keyword and enter ', h d' and type 'println' at the prompt and we get the documentation for println.

For CLI projects, I'm using Shaun Corfield's dot-clojure deps.edn, which includes an alias for 'new', which is his clojure lib to setup a project using lein templates. So, entering

clj -A:new app doctester/core

creates a basic deps.edn and project setup using CLI. Switch to the doctester/core.clj file and move the cursor to the println symbol. Start a repl with cider-jack-in-clj and then enter ', h d' and type in 'println' and you get the error. Note that the repl is working and you can switch to it and evaluate expressions fine and run tests with no issue.

theophilusx commented 3 years ago

I have done a comparison of the cider-buffer for a non-spacemacs Emacs and Emacs running spacemacs and there is no difference in the command being run to start ciider, the cider, nrepl etc versions or anything else. So it isn't that the cider repl is the problem. Both are identical.

theophilusx commented 3 years ago

I have done some more digging into this and have some more data, but unfortunately, have been unable to find the cause. Here is what I've found

  1. This is definitely only an issue with CLI based clojure projects. Everything works fine with Lein based projects.
  2. This seems to be related to nrepl-send-sync-request. Essentially, this is always returning (no-doc done) even for symbols in clojure core like println. Same lookup with a lein project works fine. Can confirm this by turning on nrepl message logging and looking in the messages log.
  3. It seems also that once you have loaded a CLI based project and then close the repl and open a repl for a Lein based project, the same issue begins to occur. Opening a lein project first and it works fine (and then opening a CLI based project still fails).
  4. I have tried minimal clojure layer configurations - basically turning off everything I can, but that has no effect.
  5. I have tried with both Emacs 28 (dev) and Emacs 27 (27.0, 27.1 and 27.1.50) with no difference.
  6. Running an emacs config without spacemacs (just plain init.el and using use-package to load the same clojure packages) and all works fine. This seems spacemacs specific.

My elsip skills are now defeating me in being able to adequately debug this issue. If anyone else can help, that would be appreciated.

rakyi commented 3 years ago

I'm unable to reproduce this also with a minimal deps.edn based project. Maybe there is something in the template or in your system (like you global deps.edn) that is causing this issue?

theophilusx commented 3 years ago

I suspect it is something on my system, but I'm lost as to what.

I doubt it is anything global as everything works if I run vanilla emacs where the packages are installed from basic init.el file

Things I've tried -

At a loss as to what is causing this

theophilusx commented 3 years ago

@rakyi would it be possible for you to share the minimal test repo you were able to get working with a CLI project?

I'm running out of ideas here. I removed my user deps.edn, leaving only the system deps.edn installed when I installed the CLI tools and have a project with a minimal project deps.edn, but still I get the error.

I've created a new account with fresh minimal spacemacs install and still same issue

I've tried on two different machines, one Linux and one macOS, same error.

I must be doing something wrong, but cannot work it out. My setup is stripped to a bare minimum and I cannot get it to work. Perhaps if I start with a repo which you have that is working, I might be able to make some progress.

What has me most frustrated is that it all works fine if I use just a basic Emacs with just elpa config and use-package statements to load cider, clj-refactor and flycheck-clj-kondo, so my global deps.edn, user deps.edn and project deps.edn all look good. Likewise, cider, nrepl are all the same versions. The only difference is the spacemacs setup and I've tried stripping that to a bare minimum as well - even tried with just the default .spacemacs and adding just the clojure layer. Also tried the ivy version rather than helm, but no luck. Have deleted .cache and elpa directories as well, but no luck.

rakyi commented 3 years ago

In directory test I created file deps.edn which contains just {:deps {}} and src/test.clj with this content:

(ns test)

(prn "hello")

Then I did this:

  1. Open src/test.clj
  2. Run SPC m ' (sesman-start) and choose cider-jack-in-clj
  3. Put cursor on prn and run SPC m h d, prompt in message area says ClojureDocs doc for:
  4. Type prn and press enter. Got message (visible in *Messages* buffer): cider-clojuredocs-lookup: Wrong type argument: char-or-string-p, nil
  5. Evaluate the buffer with SPC m e b
  6. Put cursor on prn and run SPC m h d, *cider-clojuredocs* buffer containing the docs opens

I didn't hit the error previously because I automatically evaluated the buffer knowing cider works via the REPL. But maybe that was the problem all along and you just didn't evaluate the form you were trying to look up the docs for?

theophilusx commented 3 years ago

Hmm, that is quite possible. I will do some checks.

If the form needs to be evaluated before you can look it up in the docs, that is a problem - most of the time, I look up the docs to verify how to use the symbol in a form. Hoping that it is just that the buffer needs to be evaluated and not the form you want to lookup.

Still wonder why this works outside of spacemacs without the need for evaluation. Still, very valuable bit of info you worked out - figure I should be able to get further now. Thanks for the work.

theophilusx commented 3 years ago

Just confirming your results. Also, once a buffer has been evaluated (loaded), lookup for symbols which do not appear in the buffer works fine as well (i.e. the symbol form does not need to be evaluated before the lookup will work). Also, other lookup functions like cider-doc (, h h) now work correctly. Previously, they fialed stating the symbol cold not be found. o

practicalli-johnny commented 3 years ago

According to the CIDER documentation, the first thing that should be done is to evaluate a buffer or at least evaluate one namespace. This will cause CIDER to load clojure.core functions (and those from the namespace if evaluating the buffer). https://docs.cider.mx/cider/0.26/usage/code_evaluation.html#basic-evaluation

Before that, only special forms are loaded and work with docs, e.g. def or if functions. https://practicalli.github.io/spacemacs/documentation/cider-doc.html

I assume that Leiningen is loading the relevant namespaces in automatically, so hides the fact that something needs to be evaluated first.

theophilusx commented 3 years ago

Yes, it would seem that is the issue. At any rate, remembering to eval at least one ns seems to fix the problem.

My only confusion is I was certain I tested this outside of spacemacs (simple init.el setup) and the documentation worked in cli projects. I must have had mushrooms in my dinner that night!

closing this issue as it seems to be a carbon based error.