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

[Feature request]Disable empty line between mutually recursive type #1658

Closed
cxa opened this issue Apr 17, 2021 · 3 comments · Fixed by #1691
Closed

[Feature request]Disable empty line between mutually recursive type #1658

cxa opened this issue Apr 17, 2021 · 3 comments · Fixed by #1691

Comments

@cxa
Copy link
Contributor

cxa commented Apr 17, 2021

type Cmd<'msg> = Cmd'<'msg> list
and private Cmd'<'msg> = Send<'msg> -> unit

formatted to

type Cmd<'msg> = Cmd'<'msg> list

and private Cmd'<'msg> = Send<'msg> -> unit

Preview

Can we have an option to remove the empty line above and? Thanks.

@nojaf
Copy link
Contributor

nojaf commented Apr 17, 2021

Hello,

Thank you for your interest in this project.
I'm not in favour of introducing a new configuration option for this.

We should have a better default for this.
I see two options:

  1. Go with the default multiline rule.
    So if both types are short, it just goes underneath each other without any introduced blank lines.

Helper function: colWithNlnWhenItemIsMultiline

  1. We respect fsharp_blank_lines_around_nested_multiline_expressions for this.

Helper function: colWithNlnWhenItemIsMultilineUsingConfig.

At first glance, I'm more in favour of option 1.

@cxa
Copy link
Contributor Author

cxa commented Apr 17, 2021

Hi,

Thanks for your reply.

Yes, I agree that less options is better.

Both options are acceptable, but I think option 2 is more explicit.

@nojaf
Copy link
Contributor

nojaf commented Apr 30, 2021

@cxa I went for optional two.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants