-
Notifications
You must be signed in to change notification settings - Fork 59
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
preserve location of cons comment #282
Conversation
Wouldn't this be an issue for all operators? What makes |
Yeah that is a good point. |
Well I guess what makes this case special is that it was reported by a whatsapp user. It was impossible for the user to write:
So they ended up with
which seems pretty bad |
But as you say, this problem is also true for all binary operators. |
I started looking at {op, ...} and I think that would be better solved in a separate pull request. It is not as easy a fix as this one for |
I thought about this a bit longer and my question would be - do we need to support both positions, would it make sense to only indeed support what the user expected: [
Foo
% comment
| Bar
]
%% but no
[
Foo
|
% comment
Bar
] The comment on a single line after single line Foo +
% comment
Bar
%% but no
Foo
% comment
+
Bar The trailing operator case falls out naturally from how we've structured the code. It looks like we'd need to adjust how we emit comments for the "leading" operator case to match. But we wouldn't need to alter the AST: cons_to_algebra(Head, Tail) ->
HeadD = expr_to_algebra(Head),
TailD = concat(<<"| ">>, maybe_wrap_in_parens(Tail, do_expr_to_algebra(Tail))),
break(HeadD, combine_comments(Tail, TailD),). |
I can definitely try this and also look at how it affects other binary operators. |
@michalmuskala I don't know how you did it, but again this solution is much more elegant than mine. |
Fixes #278