Here's a formatting issue I've encountered a few times. The distilled code with default settings is the following:
%% No 100-col overflow: oneliner.
ok() ->
#{k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => vvvvvvvv}.
%% 100-col overflow: formatted map.
ok_overflow() ->
#{k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => vvvvvvvv}.
%% Same 100-col overflow, but not handled correctly (assumably due to parens): no reformatting at all
not_ok_overflow() ->
(#{k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => vvvvvv}).
%% Same 100-col overflow, but handled correctly because of additional "v" char
plus_one_char_ok_overflow() ->
(#{k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => vvvvvvv}).
It's pretty explanatory, but the problem is that not_ok_overflow/0's body is not properly formatted. Hypothesis is that it happens because of how parens are treated. Took a quick dive into the code, so can't say for sure.
I do acknowledge that width-enforcement is "best-effort", but this case seems like there is something that can be improved.
Steps to reproduce
(as a shell script)
rebar3 new lib name=efmt_parens_issue
cd efmt_parens_issue/
cat >>src/efmt_parens_issue.erl <<EOF
%% No 100-col overflow: oneliner.
%% No 100-col overflow: oneliner.
ok() ->
#{k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => vvvvvvvv}.
%% 100-col overflow: formatted map.
ok_overflow() ->
#{k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => vvvvvvvv}.
%% Same 100-col overflow, but not handled correctly (assumably due to parens)
not_ok_overflow() ->
(#{k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => vvvvvv}).
%% Same 100-col overflow, but handled correctly because of additional "v" char
plus_one_char_ok_overflow() ->
(#{k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => vvvvvvv}).
EOF
echo -e '\n{plugins, [{erlfmt, "1.0.0"}]}.' >> rebar.config
cat src/efmt_parens_issue.erl | tail -n5 | head -n1 | wc -c
# Outputs 102, yet this line had to be split into multiple lines
rebar3 fmt -w
# To demonstrate how it looks
tail -n10 src/efmt_parens_issue.erl
# Yet not_ok_overflow/0 wasn't properly formatted:
# %% Same 100-col overflow, but not handled correctly (assumably due to parens): no reformatting at all
# not_ok_overflow() ->
# (#{k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => vvvvvv}).
#
# %% Same 100-col overflow, but handled correctly because of additional "v" char
# plus_one_char_ok_overflow() ->
# (#{
# k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => v, k => vvvvvvv
# }).
Here's a formatting issue I've encountered a few times. The distilled code with default settings is the following:
It's pretty explanatory, but the problem is that
not_ok_overflow/0's body is not properly formatted. Hypothesis is that it happens because of how parens are treated. Took a quick dive into the code, so can't say for sure.I do acknowledge that width-enforcement is "best-effort", but this case seems like there is something that can be improved.
Steps to reproduce
(as a shell script)