Skip to content
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

Merged
merged 5 commits into from
May 7, 2021
Merged

preserve location of cons comment #282

merged 5 commits into from
May 7, 2021

Conversation

awalterschulze
Copy link
Contributor

Fixes #278

@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Apr 28, 2021
@michalmuskala
Copy link
Member

Wouldn't this be an issue for all operators? What makes | special?

@awalterschulze
Copy link
Contributor Author

Yeah that is a good point.
We should probably make the same change for all operators.

@awalterschulze
Copy link
Contributor Author

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:

[
    {an, element}
    % comment below
    | Rest
].

So they ended up with

[
    {an, element}
    |
    % comment below
    Rest
].

which seems pretty bad

@awalterschulze
Copy link
Contributor Author

But as you say, this problem is also true for all binary operators.

@awalterschulze
Copy link
Contributor Author

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 cons_rest. Could we merge this in the mean time?

@michalmuskala
Copy link
Member

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 | looks pretty weird. Similar how for regular operators that are formatted at the end of the line we only support having them before the right hand expression:

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),).

@awalterschulze
Copy link
Contributor Author

I can definitely try this and also look at how it affects other binary operators.

@awalterschulze
Copy link
Contributor Author

@michalmuskala I don't know how you did it, but again this solution is much more elegant than mine.
I think this is ready to merge and solves the issue.

@awalterschulze awalterschulze merged commit fbbd4d5 into master May 7, 2021
@awalterschulze awalterschulze deleted the cons_comment branch May 7, 2021 14:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

comment before pipe is moved and does not preserve formatting
3 participants