Add more compilers and error formats

[hauleth]

It would be useful to have error format available at least for mix compile/elixirc beside exunit.

[teoljungberg]

One that would work for espec, and credo would be swell aswell!

[hauleth]

@teoljungberg I do not use espec, but for credo:

if exists('current_compiler')
    finish
endif
let current_compiler = 'credo'

if exists(":CompilerSet") != 2
    command -nargs=* CompilerSet setlocal <args>
endif

CompilerSet errorformat=%f:%l:\ %t:\ %m
CompilerSet makeprg=mix\ credo\ suggest\ --format=flycheck

[kelvinst]

Just to mention the current error format fails with this log:

  1) test update/2 creates or updates customer card (Teamweek.Deadwood.Stripe.CardTest)
     test/teamweek_deadwood/stripe/card_test.exs:26
     ** (UndefinedFunctionError) function Stripe.Customer.fetch/2 is undefined (Stripe.Customer does not implement the Access behaviour)
     code: assert {:ok, new_card} = Card.update(m1, "member1@mail.com", "tok_mastercard")
     stacktrace:
       (stripity_stripe) Stripe.Customer.fetch(%Stripe.Customer{account_balance: nil, address: nil, created: nil, currency: nil, default_source: nil, deleted: nil, delinquent: nil, description: nil, discount: nil, email: "member1@mail.com", id: "fake_cus_19431", invoice_prefix: nil, invoice_settings: nil, livemode: nil, metadata: %{"user_id" => "1", "workspace_id" => "1"}, name: nil, object: nil, phone: nil, preferred_locales: nil, shipping: nil, sources: %{data: [%Stripe.Card{account: nil, address_city: nil, address_country: nil, address_line1: nil, address_line1_check: nil, address_line2: nil, address_state: nil, address_zip: nil, address_zip_check: nil, available_payout_methods: nil, brand: "Visa", country: "US", currency: nil, customer: "fake_cus_19431", cvc_check: nil, default_for_currency: nil, deleted: nil, dynamic_last4: nil, exp_month: 8, exp_year: 2019, fingerprint: "v2PiY1EHDHxbvFuN", funding: nil, id: "fake_card_99389", last4: "4242", metadata: nil, name: nil, object: nil, ...}]}, subscriptions: nil, tax_exempt: nil, tax_ids: nil, tax_info: nil, tax_info_verification: nil}, "id")
       (elixir) lib/access.ex:322: Access.get/3
       (teamweek_deadwood) lib/teamweek_deadwood/stripe/fake_customer_api.ex:31: Teamweek.Deadwood.Stripe.FakeCustomerApi.update/3
       (teamweek_deadwood) lib/teamweek_deadwood/stripe/card.ex:95: Teamweek.Deadwood.Stripe.Card.stripe_customer/3
       (teamweek_deadwood) lib/teamweek_deadwood/stripe/card.ex:65: Teamweek.Deadwood.Stripe.Card.update/3
       test/teamweek_deadwood/stripe/card_test.exs:28: (test)

Quickfix shows this:

||   1) test update/2 creates or updates customer card (Teamweek.Deadwood.Stripe.CardTest)
||      test/teamweek_deadwood/stripe/card_test.exs:26
||      ** (EXIT from #PID<0.682.0>) an exception was raised:
||          ** (UndefinedFunctionError) function Stripe.Customer.fetch/2 is undefined (Stripe.Customer does not implement the Access behaviour)
(elixir) lib/access.ex|322  | nil, address: nil, created: nil, currency: nil, default_source: nil, deleted: nil, delinquent: nil, description: nil, discount: nil, email: "member1@mail.com", id: "fake_cus_18015", invoice_prefix: nil, invoice_settings: nil, livemode: nil, metadata: %{"user_id" => "1", "workspace_id" => "1"}, name: nil, object: nil, phone: nil, preferred_locales: nil, shipping: nil, sources: %{data: [%Stripe.Card{account: nil, address_city: nil, address_country: nil, address_line1: nil, address_line1_check: nil, address_line2: nil, address_state: nil, address_zip: nil, address_zip_check: nil, available_payout_methods: nil, brand: "Visa", country: "US", currency: nil, customer: "fake_cus_18015", cvc_check: nil, default_for_currency: nil, deleted: nil, dynamic_last4: nil, exp_month: 8, exp_year: 2019, fingerprint: "v2PiY1EHDHxbvFuN", funding: nil, id: "fake_card_97347", last4: "4242", metadata: nil, name: nil, object: nil, ...}]}, subscriptions: nil, tax_exempt: nil, tax_ids: nil, tax_info: nil, t

So it wrongly identifies the first line of the stacktrace on this exunit test fail as the filename and line, which is not accurate because the stacktrace is in the reverse order (first call is in the last line).

[hauleth]

@kelvinst you are talking about exunit compiler or mix compiler?

[kelvinst]

Oh, was not aware of the exunit compiler... Well, do you know how can I discover which errorformat is getting used when running it? The command being ran is: :Dispatch mix test test/teamweek_deadwood/stripe/card_test.exs, and :echo &efm prints: %A%t%*[^:]: %m,%C%f:%l: %m,%C%f:%l,%Z,%\&chdir /Users/kelvinst/Code/teamweek/core/teamweek_deadwood for me... Looks like it's using mix compiler, is there a way to set the correct compiler?

[hauleth]

You can use :compiler for setting proper compiler. However I do not know how it interacts with vim-dispatch.

[kelvinst]

Found the problem:

:Dispatch[!] [options] {program} [arguments]
                        Find a compiler plugin that sets 'makeprg' to
                        {program} and use its 'errorformat' to dispatch a
                        |:Make| for the given {program} and [arguments].  If
                        no compiler plugin is found, the generic format
                        %+I%.%# is used.

So dispatch tries to discover the correct compiler by searching by the makeprg var, and as mix compiler makeprg is set to mix, and the command we are running is mix test file.exs, it finds the mix compiler first.

What if we change mix's makeprg to mix compile? I mean, should it be used for any other mix task? Other mix tasks have very different error formats, so it will not work anyways. WDYT?

[hauleth]

IIRC some of the Mix commands shared the output, but I am not 100% sure. It probably could be fixed there to use only mix compile.

[kelvinst]

Yep, in the meantime I configured dispatch this way:

let g:dispatch_compilers = {
          \ "mix test": "exunit",
          \ "mix compile": "mix"
          \ }

But I really dislike to have these specific configurations, dispatch should work with the mix compilers without any option IMO, since it is a very commonly used plugin.

[kelvinst]

Also, actually the mix compiler errorformat is not very good too. It does not highlight compilation errors, just warnings.