Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Imagine you get a failing test and you see a test failure. You see two strings, one expected and one actual, that look perfectly identical. Searching through these strings requires awkward scrolling or copying and pasting these strings into a diff application.
This is an early version of what this could look like in Kaocha:
It's actually straightforward to support string diffing, as they are collections of characters and perfectly supported by clj-diff. We just have to merge back the characters into strings so we don't get an unreadable diff.
This only enables within-string diffing when selected. I created a second arity for backward compatability. For future use, I added a general options hash-map. I think diff is a high-level function that might benefit from other options eventually.
A possible refinement would be to treat short strings as ("cat" and "kate") as atomic values that don't get diffed and use this new handling only on long strings.
We could also use the edit difference, I suppose, so that very similar strings get their differences highlighted and ones with large differences are just shown next each other. The reasoning would be if the difference is large, it's probably obvious. (In some cases, a large edit difference may mean you may not even need the expected value, as a lot of divergences might mean the function returned completely wrong data (say, HTML instead of plain text).) However, that seems like two much of a divergence for this PR and we would probably want to add that functionality for all sequences.
But I digress. I think this change represents a significant quality-of-life improvement, and we can add other functionality as use cases appear.