That would explain a lot actually, thanks for bringing the info in.
At this point it’s clear that it’s on the community to start these initiatives. We can’t and shouldn’t rely on the core team for so much.
dimitarvp
tensiondriven
The strange thing about this particular feature is that it isn’t “reversible” - The formatter will split your code across multiple lines, but there’s no provision to “un-split” it, and not just in formatter, but not in any of the related tools (credo, etc). I’m not advocating for changing default behaviour or anything of that sort, just looking for a solution to assist in collapsing newlines that formatter would not otherwise have added.
0
LostKobrakai
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.
3
josevalim
Creator of Elixir
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.
4
tensiondriven
This is not one of those discussions, at least it wasn’t intended to be. I have no problem with the formatter.
What I am looking for is a way - any way - to re-format code with extra new lines in it. formatter isnt the tool, because it doesn’t support reverting added new lines, either by default or with flags. Credo doesn’t have support for it, that I can find.
If it weren’t for comments, I imagine I could drop all newlines from a file and then apply formatter.
If I knew my way around the Code module, it might be possible to write a custom task in fairly short order that would respect comments.
If vscode had a “select statement” command that was elixir-aware, that could be a good way to fix these as they come up.
Currently I do this manually and it’s wearing out my backspace key.
Given these constraints, recode also seems to be a viable option if support is added.
This comes up on teams that are working on existing codebases and aren’t paying attention to when it’s more appropriate to collapse extra newlines. Other languages like elm (and Haskell?) make heavy use of newlines, and people who use those languages seem less sensitive to extraneous newlines. I frequently open files and find cases where there are extra newlines that don’t appear to have been added intentionally.
So, looking for a way to clean these up.
1
dimitarvp
I think we all agree on that, I just wish we could configure that particular behavior. I understand it’s a preference that can’t and shouldn’t be argued against.
0
sabiwara
Elixir Core Team
Maybe another relevant place to add this could be the freedom formatter, which is consistent with the official formatter yet is adding some options on the top of it.
There is no collapse option yet, but it would seem consistent with its goals so a PR might get accepted?
2
dimitarvp
Thanks, bookmarked.
In terms of PRs, I wouldn’t even know where to start but I keep dreaming that one day I don’t have to think of money that much and I’ll have more free time. {sighs}
1
Marcus
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
3