-
Notifications
You must be signed in to change notification settings - Fork 26
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
More dangling functions #660
Comments
A.
B.
Not bad, actually, could keep that, although I'd prefer my first snippet. C.
Also not bad. Would want some indentation of the cases at least, probably. D.
|
@aspiwack You might have an opinion on those things. The tree sitter grammar maintainer might also have one. |
I realised today that Ormolu lets you chose whether to dangle a f = do
do_something f =
do
do_something Maybe that's a way to go? |
Is your feature request related to a problem? Please describe.
Topiary's default OCaml formatting is very aerated (especially in multi-line mode), which I enjoy quite a lot. However, sometimes, I find it too aerated and I wished some things stayed on the same line. This is for instance the case with functions (
fun x ->
andfunction
). I feel we could often opt for a slightly more compact style by making functions dangle at the end of the previous line. We currently do that specifically in the case oflet . = fun . ->
(andfunction
) but I would maybe like to see that in other situations.Describe the solution you'd like
Here are few examples of how I would format things and how Topiary actually formats them right now. I am not necessarily super attached to all of those, the goal is more to start a conversation on this.
A.
This is the case that Topiary already handles, although I would prefer it with only one indentation level.
B.
or maybe:
I would use the first one. My current editor gives no indentation level then, but I can see how we would prefer one, even if chaining such operators would then give a funny look:
Not that bad, actually. Still, This would be somewhat more compact than Topiary's output and would lead to less indentation levels. Where to put the
@@
operators is somewhat covered in #657. No matter where it goes, I think I'd prefer havingfun . ->
dangle onto it.C.
This is actually not a bad output. I think we probably want to add indentation to this operator, but I'm not sure. Again, positioning of the
>>=
operator is covered in #657. I am not sure I understand why the output is like this; is it because the operator ends with an=
?D.
or
This is probably the one that annoys me the most. I see where it comes from, and it sometimes makes sense when the lambda is a very big function, but I feel that most of the time this is too much. I would say that the style
is more common but I suppose it doesn't fit so well in our aerated style and it also behaves a bit less well with Git diffs, so maybe
is better? I have similar considerations about
function
but this issue is getting big so maybe in another comment.Describe alternatives you've considered
The current style is not bad, frankly, and I use it in a fair amount of projects. For some projects of mine, though, I have tried adding it, and really struggled with the result, especially for B. and D. Maybe I will share a snippet of an actual piece of code that I am not happy with.
Additional context
Related to #657
Related to an incoming issue on dangling tuples/lists/arrays.
I know we have discussed similar things at various points, but I am not sure where. Maybe we should link those here.
The text was updated successfully, but these errors were encountered: