Yeah, I’m not gonna be using it, since these are not bugs.
I just don’t understand why you guys committed to having parentheses, but then remove them from if statements, then completely ignore why they exist in the first place, by placing closing ones on new lines, and then double the lines of code with new line for everything, not to mention what the formatter does with code that uses long, descriptive names.
My code looks like a Tasmanian devil went and had its way with every line. 
I’ll pray that it doesn’t get adopted 
Deithrian
RomanKotov
Thank you for great formatting tool. I’ve found it very helpful.
After generating new umbrella project I started adding .formatter.exs file with the following contents:
[
inputs: ["mix.exs", "{apps,config}/**/*.{ex,exs}"],
]
But mix format failed to format some files
mix format failed for file: apps/app_web/assets/node_modules/phoenix/priv/templates/phx.gen.schema/schema.ex
** (SyntaxError) apps/app_web/assets/node_modules/phoenix/priv/templates/phx.gen.schema/schema.ex:1: syntax error before: '='
(elixir) lib/code.ex:442: Code.format_string!/2
(mix) lib/mix/tasks/format.ex:293: Mix.Tasks.Format.format_file/3
(elixir) lib/task/supervised.ex:88: Task.Supervised.do_apply/2
(elixir) lib/task/supervised.ex:38: Task.Supervised.reply/5
(stdlib) proc_lib.erl:247: :proc_lib.init_p_do_apply/3
This error is due the file with .ex extension contains some string interpolations, like defmodule <%= inspect schema.module %> do. This fact is not a problem, because entire node_modules dir is in .gitignore, so .formatter.exs inputs must skip formatting this file. I would like to share my solution of this problem, because I think someone else could find it helpful.
Now my basic .formatter.exs file looks like:
inputs = "git ls-files | grep -E \"*\\.exs?$\""
|> String.to_charlist()
|> :os.cmd()
|> to_string()
|> String.split(~r{(\r\n\|\r|\n)}, trim: true)
[
inputs: inputs,
]
So it formats elixir files only under the version source root.
kelvinst
I had the same problem, but my solution was a little bit different:
[
inputs: [
"mix.exs",
"apps/*/{config,lib,test,priv}/**/*.{ex,exs}",
"config/**/*.{ex,exs}"
]
]
josevalim
Creator of Elixir
We will tackle it in the next release, we have an open issue here: Figure out how .formatter.exs should work in umbrellas · Issue #7280 · elixir-lang/elixir · GitHub
rayex
Hi,
I like the new code formatter. I just noticed an inconsistency though between the with and if formats:
def new(type, %Coord{} = origin) when type in @types do
with %MapSet{} = coords <- coords(@offsets[type], origin),
do: {:ok, %Island{type: type, coords: coords, hits: MapSet.new()}},
else: ({:error, _reason} -> {:error, :invalid_island_args})
end
def guess(%Island{} = island, %Coord{} = guess) do
if MapSet.member?(island.coords, guess),
do: {:hit, update_in(island.hits, &MapSet.put(&1, guess))},
else: :miss
end
As you can see above, the do: and else: clauses are more indented for with than for if.
And I understand why but it just struck me.
Thanks
OvermindDL1
Yep it bugs me too, it’s because with is a multi-arity function call (ack! Those should be banned from elixir!), however you can kind of ‘work around’ it by surrounding the with ‘arguments’ with parenthesis (which is what I do now since the formatter broke my previous with\ syntax form), like:
def new(type, %Coord{} = origin) when type in @types do
with(
%MapSet{} = coords <- coords(@offsets[type], origin),
do: {:ok, %Island{type: type, coords: coords, hits: MapSet.new()}},
else: ({:error, _reason} -> {:error, :invalid_island_args})
)
end
scarfacedeb
What’s the consensus on grouping multiline functions with the new formatter?
I know that it still allows to group one-line functions, but it’s no longer possible to apply the same styling to the longer functions.
I noticed that it was a quite common way to format the code, e.g. hex.pm grouped multiline functions not long ago:
https://github.com/hexpm/hexpm/blob/c8d753f811ce7ecf20b1110fbe8d2185655e50ec/lib/hexpm/accounts/audit_log.ex#L12
But now it was run through new formatter, and I think that it looks worse (notice haphazard new lines around extract_params):
https://github.com/hexpm/hexpm/blob/master/lib/hexpm/accounts/audit_log.ex#L61
I’m aware that the formatter doesn’t know what’s a function, and therefore cannot make an intelligent decision here. But does it mean that the official position is against the old style of grouping and you aren’t planning to bring that ability back? 
sasajuric
Author of Elixir In Action
EDIT: José confirmed on IRC that the behaviour I’ve reported in this post is a bug, so I created the issue on Github.
I’ve noticed some weird formatter behaviour in Elixir 1.6.4, which I personally don’t like. I’m not sure if it’s a feature or a bug, so I’m reporting it here.
From what I can tell, the formatter seems to respect my vertical choice of function parameters. So both of the following are fine:
Enum.reduce(foo, bar, baz)
Enum.reduce(
foo,
bar,
baz
)
This is cool, because in some cases, I like to break each param on a separate line, even if the line itself is not long.
Now, if the last param is a lambda, the formatter doesn’t respect the vertical choice. In other words, if I start with this code:
Enum.reduce(
foo,
bar,
fn el, acc -> baz(el, acc) end
)
It’s always turned into
Enum.reduce(foo, bar, fn el, acc -> baz(el, acc) end)
That becomes somewhat annoying when the lambda is multiline, because my code is always force formatted into
Enum.reduce(foo, bar, fn el, acc ->
baz(el)
qux(acc)
end)
Personally, I have problems when reading this layout, because the lambda arguments are further right than the body.
This becomes particularly annoying in the following case:
Enum.reduce(
moderately_complex_expression,
moderately_complex_expression,
fn element, accumulator ->
do_something(element)
do_something(accumulator)
end
)
The code gets reformatted into:
Enum.reduce(moderately_complex_expression, moderately_complex_expression, fn element,
accumulator ->
do_something(element)
do_something(accumulator)
end)
Which I find quite terrible to read.
Of course, the code can be improved by using temp local vars and/or named functions, but in some cases I just prefer to inline everything. Sadly, given the formatted code above, inlining is not an option anymore.
So my question would be: is such formatting intended or is this a bug?
cc @josevalim
OvermindDL1
jozef
You can always use
alias Foo.Api.Google, as: ApiGoogle
alias Foo.Authentication.Google, as: AuthenticationGoogle