-
Notifications
You must be signed in to change notification settings - Fork 186
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
Fix position of expressions regarding of comments in infix-op expressions #970
Closed
Closed
Changes from all commits
Commits
Show all changes
26 commits
Select commit
Hold shift + click to select a range
ceb1383
externalize parenze_nested_exp
gpetiot 1fa17e2
externalize fmt_op_args
gpetiot ad1de6b
simplify
gpetiot 96909b2
move functions
gpetiot ef6f596
simplify
gpetiot 37a0fcc
simplify
gpetiot 5523aea
simplify
gpetiot dab154c
simplify
gpetiot 58ffaec
simplify
gpetiot 689c125
revert 4646a12aaaddffd13ee62c6a46b74735445bfb5f
gpetiot 6dd34c4
simplify
gpetiot fc28c49
simplify
gpetiot 55cc19d
rename fmt_op_args -> fmt_infix_op_args
gpetiot a5cace2
move vars
gpetiot fefd934
simplify
gpetiot 3228e50
simplify
gpetiot 1fe3b8d
simplify
gpetiot bf9b046
break comments in infix sequences
gpetiot b0b6f82
revert previous commit
gpetiot 96f6d7e
add is_monadic_id function
gpetiot f669a0a
fix breaks
gpetiot 98c6f7a
more test
gpetiot 745955e
Revert "fix breaks"
gpetiot e1ee377
fix
gpetiot 4d1e591
also for |>
gpetiot efbf87d
reuse prec to define is_monadic
gpetiot File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This causes a break just after
|>
operatorsThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that is the new behavior for all these operators, that's why I was filtering a bit (size > 2, checking the last character), so should
|>
be treated like the rest or not?I don't really have an opinion on that, and @craigfe has a diverging opinion, so if the both of you could agree, that would be great :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, I also think this break looks odd. My toy example was using infix operators at the end of each line, a la:
but when I'm writing this sort of code personally, I keep the infix operators at the start:
(or the same with
|>
). I don't really mind which of the two OCamlformat chooses to pick (this is probably a reasonably important decision), but I do care about its interaction with comments. i.e., this looks wrong to me:And if OCamlformat chooses to enforce one or the other, there is the question of what to do with input flies that are doing it the other way (comments before/after the infix operator).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(this may be an instance where it's worth having an option to select between prepending or appending infix operators)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes that would be good to have that but it requires a bigger rewrite of the code, the sequences of infix operations are currently sugared into a weird structure that mix different operators (as long as they have the same precedence, e.g.
>>=
and>|=
), so it's not as simple as it was for sequences of items separated by;
only.