If I change it to extra-deps and refresh the project, they show up among Dependencies and I can navigate to those namespaces, but not with replace-deps

IntelliJ IDEA 2022.1 (Community Edition)
Build #IC-221.5080.210, built on April 12, 2022
Runtime version: 11.0.14.1+1-b2043.25 x86_64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
macOS 12.3.1
GC: G1 Young Generation, G1 Old Generation
Memory: 4096M
Cores: 8
Registry:
    scala.erase.compiler.process.jdk.once=false

Non-Bundled Plugins:
... com.cursiveclojure.cursive (1.12.3-2022.1)

@U0567Q30W does this ring a bell or should I create an issue?

@U08BJGV6E Could you file an issue please? That doesn’t ring a bell, and I can’t find anything like it.

Sure thing will do later

Opened https://github.com/cursive-ide/cursive/issues/2689

FYI I'm on cursive 1.12.4-2022.2

This should be macroable using intellij macros

i'd be interested to see such a macro! i tried to use intellij macros for the 1st time a few weeks ago and they just didn't work as expected, AT ALL. 😞

another useful feature would be to clone the current top-level form, keep the cursor where it was, so we can start modifying the form, without loosing its previous "version". this would result in a REPL workflow, which is more similar to working from a unix shell, which is not too bad, imho... eshell can be configured to work almost this way. looking at my config, probably these lines activate this special behaviour for eshell:

(require 'em-smart)
(add-to-list 'eshell-modules-list 'eshell-smart)

to record: 1. place caret at the end of form to eval 2. start recording macro 3. eval sexp before caret 4. paredit-forward 5. stop macro recording to use: 1. caret at end of form to eval 2. execute eval-move macro

it's a known issue, there are several related open issues: https://github.com/cursive-ide/cursive/issues?q=is%3Aissue+is%3Aopen+hover

k

yes, I feel you, a thing that helps is using Clear all test markers to avoid the mouse dance around the failures

That unfortunately hides the button to open the diff viewer 😞 got a workaround for that one?

in this case the mouse dance still required, to get the mouse in the marker without hovering the failure

Sorry, I’m planning to do some work on this soon, I’ll put that in the current EAP series.

That would be huge! Thank you!!

It’s not quite clear what the best thing to do is when the output is really big. My plan is to print the current output, then if that’s too big then diff the results and print some kind of diff, and if that’s too big then fall back to “x changes in y top-level keys” or something like that. Does that sound reasonable?

Print where?

In the tooltip.

is there a way to know the size quickly? one option is to disable the hover tip with the result

a simple dummer solution is to have a config option to disable the tooltip result entirely (getting it only by opening the diff)

Yes, perhaps the hover tip could just show a summary like “x changes in y keys” or something. I pretty much immediately go for the diff anyway. But it might be helpful to see “x changes under keys :foo, :bar and :baz” or something similar.

fwiw, I never use the hover, so would be totally ok with it gone.

about the test, in cases where clojure can't determine the actual/expected, currently when clicking for the diff nothing happens, can we instead have a window with the raw result?

I’ll look at that, sure.

Actually, could you file an issue for that just so I don’t forget?

sure

https://github.com/cursive-ide/cursive/issues/2687

Thanks - is that check macro from matcher combinators?

it uses matcher combinators under the hood, you can get check from: https://gitlab.com/mauricioszabo/check

Thanks, I’ll add that to the repro case.

The match? macro from the matches combinators lib is the main one where this comes up for me.

Ok, I’ll check that one too.

I think the way to handle those should be the same down the line, unless you are going to give it some specialised implementation

There's alsonthe case when something (like a clojure.test/are or clojure.template/do-template) results in something passing a number of times and failing some times

Yes, that needs a list popup when clicking on the gutter icon.

I’m not sure if there’s an issue for that one, but that annoys me regularly so I won’t forget about it 🙂

My 2 priorities are keyboard navigability even if I have the gutter hidden and that it doesn't make the ui hang. Wondering if the intention could offer an action to put the fails into a tool window? Might be an overkill though

Yes, there’s an issue for the keyboard thing but I can’t find it right now.

https://github.com/cursive-ide/cursive/issues/2229 is an example

Ah, yes, thanks.