This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-01-30
Channels
- # announcements (5)
- # babashka (2)
- # beginners (85)
- # cider (59)
- # cljs-dev (2)
- # clojure (10)
- # clojure-europe (61)
- # clojure-gamedev (20)
- # clojure-nl (2)
- # clojure-norway (9)
- # clojure-uk (5)
- # cursive (24)
- # data-science (4)
- # datascript (8)
- # emacs (1)
- # fulcro (8)
- # graalvm (30)
- # gratitude (9)
- # hyperfiddle (71)
- # introduce-yourself (1)
- # jackdaw (1)
- # leiningen (8)
- # london-clojurians (1)
- # missionary (3)
- # other-languages (10)
- # pathom (8)
- # pedestal (18)
- # polylith (4)
- # proletarian (5)
- # reitit (7)
- # releases (4)
- # ring (8)
- # sci (10)
- # shadow-cljs (27)
- # squint (3)
- # tools-deps (2)
- # xtdb (17)
Not sure if this is a spacemacs issue but I cannot see the cider error buffer anymore.
If my code after evaluation throws an error, it's only shown in the REPL, briefly summarized.
And I have to manually type *e
into the REPL buffer to get, rather ugly, stacktrace (with no navigation, etc.)
Before, I was able to use spacemacs/cider-display-error-buffer
but now it just fails.
cider-show-error-buffer
seems to be set to always
> Starting from CIDER 1.8.0, only runtime exceptions (and not compilation errors) will cause a stacktrace buffer to be shown. This better follows Clojure 1.10’s https://clojure.org/reference/repl_and_main#_at_repl. This behavior is controlled by the cider-clojure-compilation-error-phases
configuration option. If you wish for the error phase to be ignored, and to only take cider-show-error-buffer
into account, please customize:
>
(setq cider-clojure-compilation-error-phases nil)
https://docs.cider.mx/cider/usage/dealing_with_errors.html
Hope it helps! Feel free to follow up with more questionsSomething that's missing in your OP is the kind of exception. (/ 2 0)
is a runtime exception, by default causes *cider-error*
to pop up.
But compile-time exceptions don't - normally the stacktrace for them doesn't provide actionable info
> Before, I was able to use spacemacs/cider-display-error-buffer
but now it just fails.
That's a separate concern. Cider middleware itself shouldn't fail.
If you can reproduce it on cider/nrepl latest, an issue report would be most appreciated
It's definitely not showing up for runtime exception.
I also tried (/ 1 0)
just now and the same problem.
It might be something in my setup or spacemacs so let me first try to update ...
CIDER middleware error
is definitely not normal - if you saw it once, then all subsequent usages may be broken
I didn't have time to fully try it yet but I noticed a pattern. If I type into the REPL an expression that fails, it's working correctly. But if I evaluate it from within a buffer (namespace) then it's not working (as described before)
I'm seeing this same issue with all exceptions, including e.g. (/ 2 0)
. (`*cider-error*` doesn't pop up.)
We'd appreciate a detailed issue. Please note, we released 1.13.1 just now. You should be at least on 1.13 to receive support Thanks!
So yeah, I'm on these versions:
GNU Emacs 29.2 (build 2, aarch64-apple-darwin23.2.0, NS appkit-2487.30 Version 14.2.1 (Build 23C71)) of 2024-01-19
CIDER 1.14.0-snapshot (package: 1.14.0-snapshot), nREPL 1.0.0
Clojure 1.11.1, Java 21
and whenever i evaluate using cider-eval-last-sexp inside a clojure file, i now get a red overlay within the buffer, whereas i used to get a stacktrace pop up
oh apologies! could you point me to the explanation? (i searched but must have missed it)
I might have to scratch that since you should see the stacktrace besides from the overlay (at least you're not getting nothing :) )
yeah, so i'm getting the red explanation, and then to look at the trace i have been switching to the repl buffer and evaluating *e
The behavior that is intended, and that generally I always see is:
• for (/ 2 0)
, no overlay, *cider-error*
pops up
• for adadasda
, overlay, no *cider-error*
(because that error belongs to cider-clojure-compilation-error-phases
)
So the behavior you are seeing is unintended. I think that under certain scenarios, cider sees exceptions such as yours as a compile-time exception instead of a runtime exception, so the wrong logic is chosen
if you eval (/ 2 0)
, what are the exact contents of *e
? Maybe it's wrapped in a compile-time exception?
user> *e
;; => #error {
:cause "Divide by zero"
:via
[{:type java.lang.ArithmeticException
:message "Divide by zero"
:at [clojure.lang.Numbers divide "Numbers.java" 190]}]
:trace
[[clojure.lang.Numbers divide "Numbers.java" 190]
[clojure.lang.Numbers divide "Numbers.java" 3911]
[user$eval32872 invokeStatic "NO_SOURCE_FILE" 54]
[user$eval32872 invoke "NO_SOURCE_FILE" 54]
[clojure.lang.Compiler eval "Compiler.java" 7194]
[clojure.lang.Compiler eval "Compiler.java" 7149]
[clojure.core$eval invokeStatic "core.clj" 3215]
[clojure.core$eval invoke "core.clj" 3211]
[nrepl.middleware.interruptible_eval$evaluate$fn__11226$fn__11227 invoke "interruptible_eval.clj" 87]
[clojure.lang.AFn applyToHelper "AFn.java" 152]
[clojure.lang.AFn applyTo "AFn.java" 144]
[clojure.core$apply invokeStatic "core.clj" 667]
[clojure.core$with_bindings_STAR_ invokeStatic "core.clj" 1990]
[clojure.core$with_bindings_STAR_ doInvoke "core.clj" 1990]
[clojure.lang.RestFn invoke "RestFn.java" 425]
[nrepl.middleware.interruptible_eval$evaluate$fn__11226 invoke "interruptible_eval.clj" 87]
[clojure.main$repl$read_eval_print__9206$fn__9209 invoke "main.clj" 437]
[clojure.main$repl$read_eval_print__9206 invoke "main.clj" 437]
[clojure.main$repl$fn__9215 invoke "main.clj" 458]
[clojure.main$repl invokeStatic "main.clj" 458]
[clojure.main$repl doInvoke "main.clj" 368]
[clojure.lang.RestFn invoke "RestFn.java" 1523]
[nrepl.middleware.interruptible_eval$evaluate invokeStatic "interruptible_eval.clj" 84]
[nrepl.middleware.interruptible_eval$evaluate invoke "interruptible_eval.clj" 56]
[nrepl.middleware.interruptible_eval$interruptible_eval$fn__11259$fn__11263 invoke "interruptible_eval.clj" 152]
[clojure.lang.AFn run "AFn.java" 22]
[nrepl.middleware.session$session_exec$main_loop__11329$fn__11333 invoke "session.clj" 218]
[nrepl.middleware.session$session_exec$main_loop__11329 invoke "session.clj" 217]
[clojure.lang.AFn run "AFn.java" 22]
[java.lang.Thread run "Thread.java" 1583]]}
user>
Looks normal to me
I tried cider-eval-last-sexp
specifically, at the top-level of a .clj file and I get the intended behavior
I'd check that cider-nrepl version is latest, and if you set cider defcustoms to a custom value, please dump them here
If it doesn't make a difference feel free to report an issue, also indicate if you are using Spacemacs or any other
oooo indeed, nuking all my custom cider config in init.el brings my back to the intented behavior! i probably should have tried that to begin with, and in the future if i have a cider issue.
yeah, weird, now i'm completely unable to reproduce it, even with a git restore of my old init.el
seems to be working great now. this new behavior is excellent. thank you for all your work on this, kind sir!
total mystery to me why it wasn't working (across multiple emacs restarts) until i commented out all the cider-related setqs in my init.el & restarted emacs. then, even upon uncommenting them all and restarting again, it works as expected. :man-shrugging:
Thanks to you! It's no bother. Older variations of the same question predisposed me to think it was a non-bug. I'm glad we solved the issue even if it wasn't with a conclusion.
i wonder if @U06BE1L6T (OP of this thread) is still having the issue
Should this happen again, one extra thing you can do is:
• Quit emacs
• Start emacs
• (setq nrepl-log-messages t)
• Trigger an exception
• Visit the *nrepl-log-
buffer, copy its contents to a GH report
(You can also just set nrepl-log-messages
permanently - not bad)
I have accidentally enabled some annoying feature within cider. Can someone suggest what it might be so I can turn it off.
As I'm typing, sometimes emacs suggests completions and if I press ENTER it accepts the completion. I do not want ENTER
rebound, because if I'm typing without looking at the screen (which is often the case) then it fills my buffer with text I didn't intend.
In the example shown here I typed form
ENTER expecting to go to the next line, but when I looked back it had changed form
to format
.
Here are the minor modes enabled:
is this perhaps Lsp-completion
minor mode?
I tried to look at the documentation for Lsp-completion-mode
but there's not a lot of explanation there.
I turned off Lsp-completion
minor mode and the unwanted completion looks different now. Now when I type form RETURN
it just accepts form and does not enter a new-line. better, but still annoying.
at this point the RETURN key is still bound to RET
, nevertheless pressing RETURN does not do which RET
is documented to do.
I think that company mode is the thing popping up the completions, and I think by default that happens when you pause typing for some set amount of time. I think that variable configures how long that time is, and if it's nil
you have to initiate the popup with some kind of keyboard shortcut or other.
I'll give it a try tomorrow when I return to the office