Iirc there’s a clear stance of the elixir team that the formatter is not meant to be a all purpose formatter. It’s meant to support elixir own development and therefore likely fits a lot of other elixir open source projects as well. But it just might not be the tool for enforcing custom or internal code styles.

Exactly what @LostKobrakai said. The formatter would aggressively collapse before but then a lot of people complained that sometimes they would write newlines on purpose and the formatter collapsed (and “ruined”) them. So we started respecting the user choice when it comes to newlines.

This pretty much sums up most formatter discussions. x% people are happy it works in one way, y% people are not. If we were to change it, now y% people are happy it works in one way, x% people are not.

Just in terms of reasoning, I believe it has to do with the ambiguity involved in defining “unnecessary”. For example, should the following be collapsed just because it fits in the line limit?

%{
  one: some_longer_function_name("some_arg", "some_other_arg"),
  two: "hello!"
}

That would look pretty terrible on one line (subjectively) and I believe it’s trying to allow for this type of thing. I’m personally totally cool with this as the diffs caused by tools like Prettier that put everything on a line it can make for some very painful diffs when those lines ultimately get broken up. The big downside, of course, is that you can’t just run the formatter to get stuff exactly as you want it.

The changes are not reversed because they not only happen because the formatter applied the changes, but also because a user might have written the code that way and the formatter will maintain some user preferences forward at the expense of not being able to “undo” all changes it does to code.

recode 0.2.0 has now the task SameLine. This task tries to get everything in one code line. The task is deactivated per default but the execution can be forced by mix recode --task SameLine. Keep in mind that there may be more changes than expected.
If someone has a better name for the task, please let me know.

The task can be configured with :skip and :ignore.
Imagine the following code snippet.

    test "my test" do
      x = %{
        foo: :fail
      }

      assert_raise RuntimeError, fn ->
        do_some(%{
          x: x,
          y: :foo
        })
      end
    end

recode changing this to:

    test "my test" do
      x = %{foo: :fail}

      assert_raise RuntimeError, fn -> do_some(%{x: x, y: :foo}) end
    end

and with ignore: :fn to:

    test "my test" do
      x = %{foo: :fail}

      assert_raise RuntimeError, fn ->
        do_some(%{x: x, y: :foo})
      end
    end

and with skip: :assert_raise to:

    test "my test" do
      x = %{foo: :fail}

      assert_raise RuntimeError, fn ->
        do_some(%{
          x: x,
          y: :foo
        })
      end
    end