-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Formatting turns function definitions into one long line #313
Comments
Yeah... Once again... It's because of macros 😢. I'm sorry, but katana-code / erl_syntax can't parse that code. |
Oh, that's sad to read :/. Is there a way to make the formatter ignore those specific lines, or at least the file? |
Out of curiosity: What is
Sure! Just add |
You can also use this arguably uglier and dumber version of the code that can actually be parsed/formatted 🤷🏻 : -module(bug).
-export([handle_handoff_command/3]).
-record(fOLD_REQ, {foldfun, acc0}).
-define(FOLD_REQ, #fOLD_REQ).
-define(FOLD_REQ(Field), #fOLD_REQ.?Field).
handle_handoff_command(Record, _Sender, State = #{data := Data})
when is_record(Record, ?FOLD_REQ) ->
FoldFun = element(?FOLD_REQ(foldfun), Record),
Acc0 = element(?FOLD_REQ(acc0), Record),
log("Received fold request for handoff", State),
Result = maps:fold(FoldFun, Acc0, Data),
{reply, Result, State};
handle_handoff_command({get, Key}, Sender, State) ->
log("GET during handoff, handling locally ~p", [Key], State),
handle_command({get, Key}, Sender, State);
handle_handoff_command(Message, Sender, State) ->
{reply, _Result, NewState} = handle_command(Message, Sender, State),
{forward, NewState}. |
Thanks! |
I'm not sure, I was updating an Erlang tutorial on how to set up Riak Core, and that macro is needed as part of a function needed by a behaviour. |
If I were you, @fkrause98, I would dig up that macro definition and just use the value instead of the macro. |
Thanks, I'll try doing that! |
I'd like to use this on our code base, and I'm fine with the formatter not being able to parse the code, but the show-stopper for me is that is destroys the existing formatting and dumps everything on one single line. If it is unable to parse the code, is has to leave it alone, and just print a warning pointing out what it can't parse. |
It can't "leave it alone" because that's not how this formatter works. |
Isn't it at least possible to have the parser tell you if it was able to parse the file, and if not just ignore the entire file? I was hoping to be able to apply this to our entire code base, but that won't happen if we need to review millions of line of code just to see if some function got its formatting destroyed. |
Yeah. That would be possible. We can totally add a config option to ignore unparseable files entirely. |
Sure |
FWIW with the Furthermore, when |
Describe the bug
Function definitions ends up in a unique, long line.
Before formatting:
After formatting:
To Reproduce
Define the function like above, and run rebar3 format.
You can clone this repo and run ./rebar3 format, this is the line that I'm quoting above
Expected behavior
I expected the formatting to keep my function definition like in the example above.
Rebar3 Log
Additional context
I've tried to use both:
#{parse_macro_definitions => true} and {parse_macro_definitions => false}
because I suspect the macro might be the culprit here.
The text was updated successfully, but these errors were encountered: