Janko Marohnić

@ghallberg I have been thinking about it as well on multiple occasions, but always ended up discarding it. Firstly, this feature would be difficult to add to test.vim, as all...

I haven't, I'll reopen the issue.

For me it does resolve the filename relative to the project root. Are you sure your vim session is correctly cd'd? What do you get you open your test file...

I think a failsafe of being able to manually specify the test runner you want to use is probably the most important first step. That way if the autodetection logic...

Did it work before? Do you know if this was caused by a change in vim-test? As far as I know, if you run your vim from *inside* iTerm, then...

Yes, I see what you mean. Ideally the `RAILS_ENV=test` should be _prepended_ to the test command. I could theoretically extend the API in the way that you can do something...

`ENV["RAILS_ENV"] = "test` is actually autogenerated by all major testing frameworks ([rspec-rails does it](https://github.com/rspec/rspec-rails/blob/master/lib/generators/rspec/install/templates/spec/rails_helper.rb#L2), [minitest-rails does it](https://github.com/blowmage/minitest-rails/blob/master/lib/generators/minitest/install/templates/test_helper.rb#L1)). This is much better than having to prepend each test command with `RAILS_ENV=test`....

The only time runners I wrote would call any shell commands would be when printing file content (using `cat`). However, I don't think that calling a command like `swift package...

I won’t have time to write it myself, but I welcome pull requests.

I'm open to having a variable when you can specify the environment variables: ```vim let test#{language}#{runner}#environment = {"HEADLESS": "false"} " or let test#{language}#{runner}#environment = { \ "nearest": { \ "HEADLESS":...