Mix formatter to remove unnecessary newlines?

I see there are projects like Overview — Sourceror v1.12.2 and fix/lib/fix.ex at master · wojtekmach/fix · GitHub which aim to do deeper introspection on Elixir code - all i’m looking for here is whitespace formatting.

Yep, quite a few people noticed that mix format does not aggressively collapse code that was expanded before. I don’t like it either but apparently the maintainers disagree.

There’s a tool made on top of sourceror, namely GitHub - hrzndhrn/recode: A linter with autocorrection and a refactoring tool. · GitHub (one contributor to it is @Marcus). You can check that tool out but sadly it doesn’t support the feature you and I want yet.

Brilliant, this is a start. Thanks @dimitarvp

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.

Look at OP’s 3rd example. If you manually expand – needlessly – a very short expression, then the formatter never collapses it back.

I did—At least if by third example I assume you’re talking about breaking up %{\n\ta: 1\n}. Certainly an argument could be made that if there is only one element it could collapse, but all I was trying to say was that it seems like it’s trying to keep the rule dead simple which is: “If you want line breaks in your function heads and data-structures, you got 'em.”

Sure, but that particular choice is oddly specific and I suspect it’s tied to the personal preferences of the maintainers. Which, if I was politically inclined, would say is unfair.

I like Rust’s formatter more – it’s (a) ruthless and (b) very configurable. It would collapse back the example OP gave us. Its philosophy is “if I can fit that in one line then I absolutely will”. Or “if I spot needless curly braces (only one expression) then I am removing them”. A canonical form of [minimal] code, we might say.

Most people just go with the defaults, especially if contributing to open source. But there’s also place for internal team enforced formatter config. IMO the perfect state of affairs: strongly opinionated defaults with ability to customize.

Code is not a form of personal art expression.

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.

To be clear I wasn’t saying you’re wrong, just trying to offer some reasoning as to the why it is the way it is. Although we certainly aren’t aligned on “if it can fit on one line, do it” but absolutely aligned on allowing customization for internal formatters.

Personally the only thing I really hate is not being able to put do on its own line in with statements. with can get super ugly and I find that little change makes everything dramatically clearer.

  with {:ok, foo} <- foo(),
       {:ok, bar} <- bar(foo),
       {:ok, some_longer_thing} <- some_longer_thing(bar)
  do
    something()
  end

The default with the outdent denoting the block always looks to me like someone forgot to format.

That’s a bit of a tangent but does technically have to do with whitespace

Sorry if I was unclear: I am not saying you’re wrong either. Just preferences.