Quickfix Clarification

[jherdman]

It's unclear to my newbish eyes how quickfix is supposed to work. The first point of confusion comes from the numerous strategies for which quickfix is supported, but then you state to use dispatch.vim regardless. The confusion here is that if I want to use Neomake and have dispatch available, does it do the right thing (i.e. use dispatch, it knows to use Neomake)?

The second point of confusion is that simply :TestFile -strategy=neomake is a bit surprising. Knowing that quickfix is supported I'd expect to see the quickfix window pop up automagically upon completion, or at least be given some feedback that something is running. I honestly thought I misconfigured something the first few times. Is there something that could be done here?

My thanks for your patience with these questions. My vim-fu is not so strong.

[codeinabox]

Could you please give a bit more context about which test runner you are using ie Karma, PHPUnit. Are you still having issues getting quick fix working?

[jherdman]

I'm using RSpec in this particular case. My vim-test setup looks like this:

let test#strategy = "neomake"

" Press this with terminal output to enter normal mode so you can scroll
" through terminal output
if has('nvim')
  tmap <C-o> <C-\><C-n>
end

nmap <silent> <leader>t :TestNearest<CR>
nmap <silent> <leader>T :TestFile<CR>
nmap <silent> <leader>a :TestSuite<CR>
nmap <silent> <leader>l :TestLast<CR>
nmap <silent> <leader>g :TestVisit<CR>

So, suppose I'm in "models/foo_spec.rb" I'd do this: :TestFile. The command is issued, and there is no visible indication that anything happened. After some time I get impatient and type :copen, at which point I see the quickfix, and I can navigate through errors, and said errors are annotated in the gutter as so:

[codeinabox]

Ahhh so the quick fix is being populated fine but you don't know when the tests are finished or if they failed or succeeded? The MakeGreen strategy which uses https://github.com/reinh/vim-makegreen might help as I believe it also populates the quickfix.

[jherdman]

Ahhh so the quick fix is being populated fine but you don't know when the tests are finished or if they failed or succeeded?

Yeah, exactly. I'll give that a try.

Regarding the first question as to the quickfix docs, am I correct in that your recommendation is to use dispatch.vim regardless, and that it "just knows" which strategy to use in turn?

[codeinabox]

Dispatch.vim is because it can setup the makeprg and error format so that the quickfix will be properly populated. When you use it with other strategies it acts more as a utility to do that.

[codeinabox]

@jherdman did that all make sense? Let me know if there is anything that could have been improved in the documentation.

[jherdman]

Yup. I think outside of that I have a bit of Vim homework to do. Many thanks for your help!

[janko]

The first point of confusion comes from the numerous strategies for which quickfix is supported, but then you state to use dispatch.vim regardless. The confusion here is that if I want to use Neomake and have dispatch available, does it do the right thing (i.e. use dispatch, it knows to use Neomake)?

As stated in the documentation, all the quickfix strategies use Dispatch.vim to find the correct Vim compiler. A Vim compiler is a .vim file that specifies a command (makeprg) and a regex for parsing the test output (errorformat). This is the rspec compiler, which you can manually "activate" via :compiler rspec.

When you position yourself in a Vim buffer and run :make, Vim will run the command in makeprg and use errorformat of the last activated compiler. Vim will not automatically choose a correct compiler for you, because it doesn't know which files should use which compiler. Plugins like vim-ruby may automatically activate the rspec compiler on *_spec.rb files, but even if it did, I cannot rely on that every test runner will be automatically activated.

So then test.vim uses a Vim function from Dispatch.vim to automatically select the correct compiler based on the test command (e.g. rspec spec/something_spec.rb). Dispatch.vim then searches through all available compilers, and returns the first compiler whose makeprg matches the prefix of the test command. Then test.vim runs compiler <selected-compiler>, and afterwards it runs the selected strategy (in your case :Neomake).

Test.vim will run whichever strategy was configured. If you have both Dispatch.vim and Neomake installed, and you select let test#strategy = "neomake", then it will run Neomake.

The second point of confusion is that simply :TestFile -strategy=neomake is a bit surprising. Knowing that quickfix is supported I'd expect to see the quickfix window pop up automagically upon completion, or at least be given some feedback that something is running. I honestly thought I misconfigured something the first few times. Is there something that could be done here?

What kind of feedback you're going to get once the test command is executed by the strategy depends entirely on that strategy. Neomake seems to not give you any feedback whether the command has run (I also don't like that, Neovim with the default strategy works best for me). MakeGreen.vim let's you configure an icon that will say whether the test is running, whether it has completed successfully or whether it failed. Dispatch.vim will open a split window in which you can see the test output (provided you are using tmux, but it has great fallbacks).

The point is that test.vim doesn't have any opinions whether some strategy will work for you, it instead gives you the options to choose for yourself. If some strategy doesn't give the flexibility needed, that should be fixed in that vim plugin, not in test.vim. Test.vim is only a thin wrapper which knows how to call a strategy.

I think outside of that I have a bit of Vim homework to do.

Yeah, Vim compilers and quickfix require a bit of knowledge, it was confusing for me too at first. However, I wouldn't like test.vim README to be a source of documentation for this (because it's a generic Vim feature), though I'd be open for linking to a markdown file inside the repo with an introduction similar to above.

[jherdman]

That was an excellent read. I feel like it would make an excellent addition to the docs as it really made it abundantly clear what's going on. If not the README, perhaps the wiki?

[maxkerp]

I totally agree with @jherdman ! I couldn't figure out why using :Dispatch rspec % was populating the quickfix window correctly, so that you can move to the file and column where the error occurred, but :TestFile -strategy=dispatch was not. The quickfix winodw was only text with no highlighting or functionality.

Turns out :TestFile -strategy=disptach uses bundle exec rspec % instead of rspec % and the compiler for bundle exec does not apply rspec errorformat (which it correctly shouldn't do).

But I wouldn't have come to this conclusion without your comment although you explain it correctly in the README. Your comment does make it a bit clearer for newcomers to quickfix windows. This should be somewhere better visible than an issue. Maybe in the README under Troubleshooting > Quickfix Window. On the other hand maybe a link to a good quickfix window explanation will suffice, :h quickfix is a bit hard to get.

Nonetheless thanks a lot for your work! :+1:

@jherdman What plugin does annotate the gutter for failing specs?

[jherdman]

@maxkerp hey, sorry for the very late response. I was using Neomake to get the gutter annotated. It just did it automatically.

[maxkerp]

No big deal, thanks a lot for your answer. I have to take a closer look at neomake then.