It's https://github.com/clojure-emacs/cider/blob/25c51fd4b1246801ba3fa15c57b44d860772417c/CHANGELOG.md#L132-L133 If you wish to roll back, you are free to customize cider-clojure-compilation-error-phases 🙂

I think I'm still struggling to follow exactly. Is the new behavior that a popup is selectively added dependent on the error phases value, with the default being that if it's a compilation error and not a runtime exception there is no popup, but if there is a runtime exception it pops up? I'm well aware I'm fighting with muscle memory here, but I think I'm struggling with differentiating between the kinds of errors, so I'm just hitting q because I'm used to that? I do have cider-show-error-buffer t set, which is why I guess I assume there should be a popup. Maybe I need to experiment with that off again, or try it with cider-auto-select-error-buffer nil? Very much appreciate this is a workflow issue, I think I'm just having a hard time understanding what the intended workflow is here?

The overall reasoning is that for compile-time (or read-time, macroexpand-time) exceptions, the stacktrace is largely irrelevant and shouldn't be shown (unless the user requests it afterwards). Most times the cause of such exceptions is clearly summarized in the ex-message that we render inline. In terms of 'workflow', the workflows I would describe are: • compile-time error, I see an inline overlay, move on (e.g. fix my code and re-eval) • runtime error, inspect the stacktrace, fix the root cause somehow, close the stacktrace, re-eval ...I hope this is a satisfactory answer, LMK if you think there's a possible point of improvement.

Hmm. Ok, now that I think I better understand the change, I might be able to retrain the muscle memory. I think part of is it even with the inline messaging I've trained to assume I need to exit the window. I wonder if the inline messaging itself is also slightly tripping me up. I think in general for compilation errors I'm used to paying attention to squiggle underlines + fringe marker and mode-line error as provided by flycheck/flymake and default elisp. What I wonder is if the inline messaging response is more intrusive than necessary for a compilation error and triggers me to respond as if it's more serious? I will try and adjust from here now that I better understand the behavior, but I am curious if the inline compilation error should be less intrusive like it is in other environments?

It sounds like a reasonable thing to want. I wouldn't change the default but we'd certainly open the doors to an opt-in style that used squiggly lines and/or some other system (flycheck, particuarly, which I have no experience with). It it's something you'd see yourself working on, issue welcome

Personally I'd find squiggly lines sort of an odd choice. I think the issue boils down that 'compilation errors' are different in Clojure - there's a blurry line between compile-time and runtime. So as I view it, an error should be something that clearly indicates that you've run this code. Typically, a squiggly line indicates that the code is wrong before even being run. That's not to say the squiggly approach is wrong - simply it's something worth reflecting on before commiting to a particular change.

To clarify, I think mostly I expect the mode-line error ala elisp on compile-buffer failure, with the squiggle and fringe to help indicate where.

sorry, not compile-buffer, eval-buffer

Mind to share a screenshot for an Elisp example?

After running eval-buffer

Is that the minibuffer? IIRC we show the error message in the minibuffer for some code paths Between the minibuffer, the fringe, and that we jump to the culprit line, I consider the UX reasonably intuitive

Again, the door is not closed to squiggly - but I'd be afraid of complecting flycheck for cider + other stuff (notably clj-kondo)

Sorry, yes the minibuffer, not mode-line, my mistake. Is there a way to disable the red overlay on compilation errors though and only have the minibuffer error in Cider?

Yes, check the cider-use-overlays defcustom, it has a few possible values

Hmm, I think what I'm getting at is that I don't think I'm opposed to the red overlays if it's a runtime exception as it clearly shows that there is a problem here and everything had to stop because of it. If there is a compilation error though, it's surprising as while I still need to fix it to proceed, the red overlays are making me assume something has blown up instead of just that I need to fix something before I can get in new code. As far as I read that defcustom it looks like that turns it on or off for errors/evaluations, but doesn't make any distinction between runtime errors for compilation errors. Now that I understand the intended pattern a little better I will try and adjust to it and see how it feels. I think my instinct here is this feels like a more strident error than necessary during compilation, but I'll give it some time to adjust to see.

Your call 🙂 with cider-use-overlays set to nil you'd get the minibuffer behavior, or perhaps by customizing cider-error-overlay-face you'd find a less strident color. Feel free to pick up the conversation if these don't turn out to be convincing.

Yea, but I absolutely want the use-overlays to show the result of evaling something. That's a feature I depend on, and I also appreciate it showing the source of the error if it's a runtime exception, it's just the compilation errors that are tripping me up I think. I do see that use-overlays is already split between cider-debug-use-overlays. It might the case that it would be better if there was cider-eval-use-overlays, cider-compile-error-use-overlays, and cider-runtime-error-use-overlays. Or just a list of options for each of those. Anyway, again, I'm going to try and adjust as is now that I understand, but trying to explain what about this feels off from standard emacs workflows I'm used to.

We could extend the semantics, yes - we did so recently https://github.com/clojure-emacs/cider/pull/3524/files . except-errors sounds easy to convey. Either way I appreciate the willingness to try things as-is for now 👍