Fork me on GitHub
#cider
<
2024-01-30
>
jumar09:01:49

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

👀 1
vemv09:01:16

> 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 questions

vemv09:01:09

Something 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

vemv09:01:12

> 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

jumar13:01:31

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 ...

vemv13:01:16

CIDER middleware error is definitely not normal - if you saw it once, then all subsequent usages may be broken

👍 1
jumar11:01:54

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)

aiba05:02:27

I'm seeing this same issue with all exceptions, including e.g. (/ 2 0). (`*cider-error*` doesn't pop up.)

vemv05:02:06

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!

aiba05:02:45

i guess i'm on 1.14.0-snapshot

👍 1
aiba05:02:33

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

vemv05:02:50

and cider-nrepl?

aiba05:02:32

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

aiba05:02:42

this is how it now looks:

vemv05:02:58

Ok, that issue is different from this thread and has been explained quite a few times

aiba05:02:00

oh apologies! could you point me to the explanation? (i searched but must have missed it)

vemv05:02:56

I might have to scratch that since you should see the stacktrace besides from the overlay (at least you're not getting nothing :) )

aiba05:02:01

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

vemv05:02:57

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)

vemv05:02:43

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

aiba05:02:02

that would explain it!

aiba05:02:24

i'M getting the same behavior for both cases

aiba05:02:59

could it be because i'm using refactor-nrepl middleware? i can try disabling that.

vemv05:02:08

Seems very unlikely

vemv05:02:29

if you eval (/ 2 0) , what are the exact contents of *e ? Maybe it's wrapped in a compile-time exception?

aiba05:02:09

great question, i'll check

aiba05:02:12

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> 

vemv05:02:08

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

vemv05:02:14

(I also use refactor-nrepl)

aiba05:02:46

oh cool. the above is with refactor-nrepl disabled fwiw.

vemv06:02:18

I'd check that cider-nrepl version is latest, and if you set cider defcustoms to a custom value, please dump them here

aiba06:02:09

cider/cider-nrepl {:mvn/version "0.45.0"}

👍 1
vemv06:02:20

Intended behavior:

aiba06:02:23

i'll try it with removing all my init.el changes to any cider vars

👍 1
vemv06:02:58

If it doesn't make a difference feel free to report an issue, also indicate if you are using Spacemacs or any other

aiba06:02:48

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.

aiba06:02:06

now i'll try a binary search of the setqs to find the culprit 🙂

👀 1
vemv06:02:30

Maybe cider-show-error-buffer or cider-clojure-compilation-error-phases ?

aiba06:02:24

i think it's caused by (setq cider-popup-stacktraces t)

vemv06:02:32

cider-popup-stacktraces disappeared from cider, that can't be it :thinking_face:

aiba06:02:09

yeah, weird, now i'm completely unable to reproduce it, even with a git restore of my old init.el

aiba06:02:51

well, i'm really sorry for the bother!

aiba06:02:09

seems to be working great now. this new behavior is excellent. thank you for all your work on this, kind sir!

aiba06:02:30

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:

vemv06:02:27

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.

aiba06:02:07

i wonder if @U06BE1L6T (OP of this thread) is still having the issue

vemv06:02:59

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)

Jim Newton16:01:46

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.

Jim Newton16:01:51

Here are the minor modes enabled:

Jim Newton16:01:18

is this perhaps Lsp-completion minor mode?

Jim Newton16:01:48

I tried to look at the documentation for Lsp-completion-mode but there's not a lot of explanation there.

Jim Newton16:01:13

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.

Jim Newton16:01:24

at this point the RETURN key is still bound to RET, nevertheless pressing RETURN does not do which RET is documented to do.

Ed17:01:52

does (setq company-idle-delay nil)help?

1
Ed17:01:37

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.

☝️ 1
1
Jim Newton18:01:20

I'll give it a try tomorrow when I return to the office

Jim Newton15:01:34

It seems company-idle-delay does the trick. thanks @U0P0TMEFJ

👍 1