Łukasz Jan Niemier

@tsloughter TBH I would expect tests to be recompiled on each `rebar3 ct` call as environment could change in the meantime and it could also invalidate generated modules.

My approach would be to remove `_build/test/lib//tests` after each `rebar3 ct`, but I assume that it is unwanted solution. In my [`mix_erlang`](https://github.com/kobil-systems/mix_erlang/blob/a49b81031eaeeb56e55837e93777ab72a2795104/lib/mix/tasks/ct.ex) library I am compiling test modules in memory...

@ferd I feel like we didn't understood each other. I was talking about always recompiling only Common Test files (if that is feasible in Rebar3), rest of the compilation artifacts...

@jordwalke the problem is that even if this isn't reachable from master you need to download ALL binaries from GitHub even if you do not care about built releases. And...

I am working on formatter for Elixir projects that use Mix (aka almost all of them). I want to test whether the produced file contain all entries it should contain....

:+1: for TCO instead of loops. After that it would be nice to have macros like `loop` that would simplify that, but with TCO.

But that is how loops In Lisps works, almost. In Scheme there are loop macros which translates almost to that (they use `let` to not pollute global namespace). ## Łukasz...

@murarth alternatively you could provide only general `loop` with `break` and implement rest using macros.

Not only mirror, but it is much easier to manage external repo (due to fact how Vim plugin managers works) and to update them independently.

I have switched to NeoVim some time ago and vim-plug is quite useful solution there. But I can delieve that there are people who still use vanilla Vim without plugins.