This will be a huge win!!

I hope so! I’m not sure yet how it will perform for really big structures (the return value has to contain both sides of the diff, and the UI might be interesting too).

It'd perform equivalently to how it performs in the clojure.test integration, I'd assume?

Right, but I suspect people will use this with larger results.

Ah. Probably right. Maybe generate some large data with test.check and see what happens 😅

Yep. I can probably create an option to elide identical values in maps and replace them with ... or something too.

Ooo. That'd be awesome and useful even for the test integration!

One thing that's always been really tough to parse out is when a set of maps differs from the left and right sides. The diff UI seems really tricky and perhaps some assumptions had to be made. I could find an example if interested.

Yes, I’d definitely be interested in an example.

It’s definitely hard to know how to present arbitrary diffs, since it’s impossible to know how arbitrary data structures should be formatted.

Yeah. I have no idea how you'd even present the diff for a set of maps in the correct manner, now that I think about it. You don't know the semantics of the things I want compared since they're in a set.

Right, and it’s often obvious to the user how you would want that data formatted, but that can’t be determined automatically. If you have suggestions about how it might work I’m all ears.

I’ve thought about showing the diffs as a collapsible tree, but haven’t got around to a proof of concept for that.

Sent a follow up with a difficult map+set diff via DM. I don't have any ideas on that one since it seems very hard to do for arbitrary data.

Here's one I've gotten used to at this point: list vs vector show up in the diff even though they will be treated as =.

(= '(1 2 3) [1 2 3])
=> true

I’m truly shocked by that.

Those things are not equal by anyone’s definition.

Haha. It has some weird consequences too. It does happen to be useful in tests a lot since the vector literal is nicer to type than (list ...). Fun thread on the topic: https://clojurians.slack.com/archives/C03S1KBA2/p1621184012406400

Maybe you've seen this already, but here's another interesting approach: http://fazzone.github.io/autochrome.html

Yep, there are a bunch of them - deep-diff2, editscript and a couple more.

One other thing I was curious about. If a test reports :expected and :actual keys and is not an is form, could the diff still be shown?

Umm… maybe? I’d have to go back and refresh my memory of how clojure.test works. What’s your use case?

Support for match? https://github.com/nubank/matcher-combinators/blob/551b6f5e915d523027cb4f26ecfe3c5423ac859f/src/clj/matcher_combinators/clj_test.clj#L38 Right now I have to manually run the test to view results.

From a naive perspective, it seems reasonable that any test report that contains an expected and actual could render the diff viewer.

Seems reasonable, I’ll take a look.

Anyway, thanks for working on the diff api function. That will be really helpful.

This is a really promising feature, thanks Colin!

So there are two places where you can configure profiles, and they do different things. There’s this: https://cursive-ide.com/userguide/leiningen.html#working-with-profiles, which is used when syncing the project to the IDE. And then you can also select the profiles to be used when constructing the classpath in your REPL run configuration, and that will be used to start the REPL (or other task). Does that make sense?

It sounds like you’re talking about running a REPL, so it’s probably the second of those. You can find the selected profiles in the run config.