Closed vemv closed 7 months ago
Besides printing errors to the minibuffer, I'm also getting an overlay when I run tests.
Are you on Timbre as well?
Yes.
(Mostly a note to self)
The cause might be that Clojure compilation errors and Timbre errors are both captured under a regex.
So maybe stuff that was exclusively meant for Clojure compilation errors is also being triggered for Timbre.
I can repro the minibuffer output issue, but not the overlay issue
My attempt was the running following deftest:
(ns timbre
(:require
[clojure.test :as t]
[taoensso.timbre :as log]))
(log/error 1)
(t/deftest foo
(t/is (zero? 1)))
(NOTE: for best results, modify the buffer each time before running the tests)
Could you please describe repro steps?
One thing I've noticed at the nrepl-messages level is that replies with Timbre err output correspond to overly old requests:
(-->
id "22"
op "test"
session "8286fdd4-64f1-4787-b6a7-22fd1af87ed0"
time-stamp "2023-11-16 20:22:15.516106000"
fail-fast "true"
load? "true"
ns #("timbre" 0 6 (fontified t cider-locals nil cider-block-dynamic-font-lock t face font-lock-type-face))
tests ("foo")
)
(<--
id "15"
session "8286fdd4-64f1-4787-b6a7-22fd1af87ed0"
time-stamp "2023-11-16 20:22:15.883850000"
err "2023-11-16T19:22:15.517Z vemvs-MacBook-Pro.local ERROR [timbre:8] - 234
"
)
Note how the request has id "22" but the error reply is for "15" - quite a few messages behind.
It's as if the original eval
for 15 got "stuck" or was "greedy" in correctly releasing err.
We haven't changed stderr handling at nrepl level. We have https://github.com/clojure-emacs/cider/issues/3206 though.
I don't think this issue is releated to the overlay improvements since there's also the minifbuffer issue.
I'll see what happens if I downgrade Timbre.
I've created a simple project with the following test:
(ns com.example.app-test
(:require
[clojure.test :refer [deftest is]]
[taoensso.timbre :as timbre]))
(deftest foo-test
(try
(throw (ex-info "Some error" {}))
(catch Exception e
(timbre/error e (ex-message e))))
(is (= {:one 1
:two 2
:three 3
:five 5
:six 6}
{:four 4})))
My CIDER settings:
(setopt nrepl-hide-special-buffers nil
nrepl-use-ssh-fallback-for-remote-hosts t
cider-eldoc-display-context-dependent-info t
cider-font-lock-max-length 1000
cider-repl-display-help-banner nil
cider-repl-use-content-types t
cider-repl-wrap-history t
cider-repl-pop-to-buffer-on-connect 'display-only
cider-show-error-buffer 'except-in-repl
cider-auto-mode nil
cider-use-tooltips nil
cider-enrich-classpath t)
The error is reproducible for me:
*nrepl-messages*
when I'm running test:
I've just checked with emacs -q
and I can still reproduce it with default Emacs and CIDER settings:
I've just evaluated in *scratch*
buffer:
(package-initialize)
(require 'clojure-mode)
(require 'cider)
After some investigation I came to conclusion that CIDER renders an overlay for whatever is printed to System/err
:
So this bug can be reproduced even without timbre:
(deftest foo-test
(binding [*out* (java.io.PrintWriter. System/err)]
(println "This is an error"))
(is (= {:one 1
:two 2
:three 3
:five 5
:six 6}
{:four 4})))
To fix this issue for timbre in particular one can change the default configuration as:
(timbre/merge-config! {:appenders {:println (timbre/println-appender {:stream :*out*})}})
this will force printing all log messages to System/out
. I've put this to the user
namespace to apply it for CIDER session.
After some investigation I came to conclusion that CIDER renders an overlay for whatever is printed to System/err:
I tried that just now and couldn't repro it.
Does it happen with a stock emacs and empty clojure project with no user profile?
Yes, I can reproduce it with emacs -Q
:
deps.edn
:
{:paths ["src" "test"]
:deps {}}
test/com/example/app_test.clj
:
(ns com.example.app-test
(:require
[clojure.test :refer [deftest is]]))
(deftest foo-test
(binding [*out* (java.io.PrintWriter. System/err)]
(println "This is an error"))
(is (= {:one 1
:two 2
:three 3
:five 5
:six 6}
{:four 4})))
Run test using C-c C-t C-t
.
Thanks! Will check out again
FYI I think it's this code
The surrounding lambda is what we call a stderr-handler
. But it certainly doesn't mean to show an overlay for every line of stderr.
It intends to operate over errors passed as nrepl response attributes.
I've seen this work as intended for many months now - stderr works, and errors show as an overlay.
If you wish to give it a shot, that would be most welcome as I cannot immediately reproduce the issues you're experiencing.
vemv @.***> writes:
FYI I think it's this code
The surrounding lambda is what we call a
stderr-handler
. But it certainly doesn't mean to show an overlay for every line of stderr.It intends to operate over errors passes as nrepl response attributes.
I've seen this work as intended for many months now - stderr works, and errors show as an overlay.
If you wish to give it a shot, that would be most welcome as I cannot immediately reproduce the issues you're experiencing.
Thanks. I'll try to dig into it when I have some time. From my current understanding, it might be not CIDER's fault, but maybe cider-nrepl or nrepl, I don't think this response should be sent in the first place.
From the nrepl-messages:
Request:
(--> id "11" op "load-file" session "6c6c3a29-73ef-4786-b413-aa19af884873" time-stamp "2024-01-17 09:41:53.574781000" file "(ns com.example.app-test (:require [clojure.test :refer..." file-name "app_test.clj" file-path "/Users/rrudakov/Personal/Projects/clj-bug/test/com/example/a..." )
Response:
(<-- id "11" session "6c6c3a29-73ef-4786-b413-aa19af884873" time-stamp "2024-01-17 09:41:58.793757000" err "This is an error " )
-- Best regards, Roman
Thanks! Maybe it wasn't quite safe to assume that err
represents an exception. I don't use load-file
as much as other ops.
I'd wager that load-file
hasn't essentially changed in ages.
So, we could change the (cider--maybe-display-error-as-overlay phase err end)
to only run if err
does look like an exception.
Just 1LOC before, there's a (cider--error-phase-of-last-exception buffer)
call which internally performs an analyze-last-stacktrace
call, which is as accurate as we can get for exception analysis.
Which is to mean, thankfully the necessary data is already there, computed for us.
Will see what I can do with that - I probably don't need more investigation atm.
vemv @.***> writes:
Will see what I can do with that - I probably don't need more investigation atm.
Best regards, Roman
https://clojurians.slack.com/archives/C099W16KZ/p1700123927174669
Partial workaround:
(setq inhibit-message t)