Suggestion: Easy way to open a diff of Expected vs Actual

[idbrii]

When my tests have a lot of Given text, it can be difficult to see what's wrong in the Vader output. It would be useful if I could hit <CR> on a line in the failing test in the [Vader] window to open a new tab with a scratch buffer for given and another for expected and set both to diff mode. Viewing in a diff would make it easier to see what's wrong.

The functionality I'm looking for is something like this:

nmap <buffer> <CR> /- \v(Expected<Bar>Got)<CR>jvai"1ynjvai"2y:DiffDeletes<CR>

Which uses textobj-indent (vai) and diffusable (DiffDeletes). Here is the code to diff the input text blocks (it depends on itchy).

(That map works well enough for me if I drop it into ~/vim/after/ftplugin/vader-result.vim, so I'm fine with closing this as out of scope.)

[junegunn]

Thanks for the suggestion. Showing diffs in splits definitely makes sense and should be a nice addition to vader. I've been also thinking about improving the error report but haven't found time to work on it. One of the things I've been wanting to have is an easy way to synchronize the vader-result buffer and the buffer that shows the failed test case. Pressing enter on quickfix window will open the test case in a new split, but the view of the report page is not changed accordingly, so I have to search through the (X)s to go to the right position on the report.

[junegunn]

Hey, it's updated. Try it and let me know what you think.

[justinmk]

Works nicely! But since a good deed never goes unpunished, here's a small request: it seems to only sync all windows if <enter> is pressed in the quickfix window. It doesn't sync the top window if ]q and [q are used (from unimpaired.vim). I think this could reasonably be solved by using QuickFixCmdPost autocmd.

[junegunn]

Hi Justin, I don't use unimpared, are they mapped to :cnext and :cprev? Here I'm using a sloppy hack that extracts the line number of the report from the description of the error. I wonder if there's a better way to achieve this.

[justinmk]

are they mapped to :cnext and :cprev

Yes.

? Here I'm using a sloppy hack that extracts the line number of the report from the description of the error

Unless I'm mistaken, you could just let <enter> or :cnext do its thing, then get the line number with a plan old line('.').

But it's a moot point I think, because au QuickFixCmdPost cnext echom 'hi' isn't working for me...

[junegunn]

Unless I'm mistaken, you could just let or :cnext do its thing, then get the line number with a plan old line('.').

Well, since <Enter> will only bring me to the line of the test case in the vader file (the middle window), I can't use line('.') to find out the corresponding line in the [Vader] buffer, the top window. So that's why I'm putting the extra line number in the description of the error, and extracting it using <Enter> mapping. I think this trick won't work with :cnext or :cprev.

au QuickFixCmdPost cnext echom 'hi' isn't working for me

Yeah, looks like it's not the event we can hook into.

                            *QuickFixCmdPre*
QuickFixCmdPre          Before a quickfix command is run (|:make|,
                |:lmake|, |:grep|, |:lgrep|, |:grepadd|,
                |:lgrepadd|, |:vimgrep|, |:lvimgrep|,
                |:vimgrepadd|, |:lvimgrepadd|, |:cscope|,
                |:cfile|, |:cgetfile|, |:caddfile|, |:lfile|,
                |:lgetfile|, |:laddfile|, |:helpgrep|,
                |:lhelpgrep|).
                            *QuickFixCmdPost*
QuickFixCmdPost         Like QuickFixCmdPre, but after a quickfix
                command is run, before jumping to the first
                location.

[justinmk]

Oops, I had assumed that cnext was listed in that help item. :dizzy_face:

[idbrii]

Tested 2626295 -- original suggestion works great.