Reduce multiple blank lines to a single one.

[nojaf]

I propose we add a new setting to reduce multiple blank lines to one single blank line.

The existing way of Fantomas deals with this problem is always restoring all the found blank lines.

Pros and Cons

The advantages of making this adjustment to Fantomas are that the number of blank lines is also more consistent. If the source text contains a multitude of blank lines, this will stay there after formatting. This is undesirable as Fantomas already has some heuristics in place for placing blank lines. To remain consistent, the user should not be in control of this.

The disadvantage of making this adjustment to Fantomas is introducing yet another setting. As this proposal changes the default behaviour, I'm sure that some users will prefer that all blank lines are preserved.

Examples

let a =
    // ...
    // ...
    42



let b = 17

would be formatted to

let a =
    // ...
    // ...
    42

let b = 17

Technical remarks

In the past, I recall an experiment where no blank lines were preserved as trivia. This didn't work out in all scenarios.

module X

// foo
let a = 0

would have lead to

module X
// foo
let a = 0

Due to the way colWithNlnWhenItemIsMultiline works.

It seems viable to reduce the number of blank lines assigned to a trivia node, but not to remove them completely.
This reduction should be done in Trivia module to ensure everything in CodePrinter works as expected.

Extra information

When the design is complete, this should be added to the next major branch (v5, get-back).

Estimated cost (XS, S, M, L, XL, XXL): S

Related suggestions: I'm pretty sure this has been requested in the past, but I could not find the issue anymore.

Affidavit (please submit!)

Please tick this by placing a cross in the box:

• I have read the Contribution Guidelines.
• I have searched both open and closed suggestions on this site and believe this is not a duplicate

Please tick all that apply:

• This is not a breaking change to Fantomas
• I or my company would be willing to help implement and/or test this
• This suggestion is part of the Microsoft style guide (please add a link to section if so)
• This suggestion is part of the G-Research style guide (please add a link to section if so)

//cc @jindraivanek @JonCanning

[auduchinok]

Please allow having 2 blank lines between top level declarations (types, members, bindings), as it's often used for a better visual splitting of the declarations.

In R# formatter we have a setting for controlling max blank lines between declarations, maybe a similar one could be useful here?

[nojaf]

Perhaps, we should make it somewhat controllable by introducing two settings, one for top-level declarations (SynModuleDecl.*) and one for all the rest. The settings could be integers, where you can control the max level of preserved blank lines.

[nojaf]

Ok, this also makes me wonder about the following:
If someone has fsharp_blank_line_level_top_level_mdl=3 (setting name is just an example).
And before the code was:

module Foo

let a = 0
let b = 1
let c = 2

should that transform everything to

module Foo



let a = 0



let b = 1



let c = 2

Or only add the number of blank lines if the expression is multiline (similar to how our current rules work) 🤔?
If we try to respect that number of blank lines, we should not care about any existing blank lines.
Given enough control, that might be sensible.

Another interesting thing would also be code comments, do they make the code block multiline?

let a = 0
// Is `b` multiline because of this comment?
let b = 9

I think this used to be hard to distinguish, but the situation may have improved because of

fantomas/src/Fantomas/Context.fs

Lines 17 to 18 in 4a4a853

	| WriteLineBecauseOfTrivia
	| WriteLineInsideTrivia

[auduchinok]

We've been thinking about what settings we'd introduce for F# that would follow the C# implementation and here're some of the settings we've settled on (settings with their default values):

BlankLinesAroundSingleLineModuleMember, 0 // min lines
BlankLinesAroundMultilineModuleMembers, 1
BlankLinesAroundDifferentModuleMemberKinds, 1 // always add a blank line between e.g. an `open` and a `let` module members
KeepMaxBlankLineAroundModuleMembers, 2

Some more settings are here.

[jindraivanek]

Thanks @nojaf for creating this.

For me, ideal would be option that would say: "disregard all empty lines, Fantomas decide where empty lines will be".

I can imagine some settings like "keep empty lines up to this number" shouldn't be too hard to add.

Another interesting thing would also be code comments, do they make the code block multiline?

let a = 0
// Is `b` multiline because of this comment?
let b = 9

I think not.

[auduchinok]

Another interesting thing would also be code comments, do they make the code block multiline?

In R# formatter we consider comments attached to declarations/statements below, making them multiline.

[nojaf]

Thanks for sharing these settings @auduchinok, it is interesting to see the level of control this provides.
I think if we have something similar, then we don't need to care about what the original blank lines were in the source code.
This would simplify things in CodePrinter.
What does BlankLinesAroundDifferentModuleMemberKinds include?

While revisiting this entire problem space, we should also incorporate fsharp_blank_lines_around_nested_multiline_expressions. This setting should be translated to the number tweaking approach.

I'm still on the fence in regards to comments making items multiline.
If you something like:

let a = 0
// let b = 1
let c = 2

The // let b = 1 `` doesn't really belong to either aorc`. The user just commented out that binding. After formatting, it could end up like this:

let a = 0

// let b = 1
let c = 2

Which might not be ideal. There will of course be examples where this does make sense.

[auduchinok]

I think if we have something similar, then we don't need to care about what the original blank lines were in the source code.

The last setting in the example shows we should care about original blank lines :)

With default value of 2 it'll not add more lines in the first example and will reduce blank lines in the second one:

let a = 1

let b = 2

let a = 1



let b = 2

What does BlankLinesAroundDifferentModuleMemberKinds include?

It checks module member kinds, so the following

open A
open B
let a = 1
let b = 2
do ()

gets formatted into

open A
open B

let a = 1
let b = 2

do ()

[nojaf]

I still don't quite understand the value of KeepMaxBlankLineAroundModuleMembers?
Why bother keeping track of the original lines between and not respecting a preferred fixed number?
This would lead to inconsistency of blank lines because developer A and developer B have different handwriting?
Or what am I missing here?

[auduchinok]

Sometimes you do want a better visual separation and sometimes not. Consider multiple groups of related declarations. It really helps a lot if you add another blank line in a bigger file to split them. I believe taking this option away would be really bad for some (many?) folks.

[jindraivanek]

Because writing code is more fun than lengthy comments, I hereby present to you Proof Of Concept of this feature, featuring option MAX_ORIG_NEWLINES as constant.

master...jindraivanek:experiment/remove-extra-newlines

Doing this with one global option is quite easy, multiple options for different node types would be considerably harder.

You can see this in action on Fantomas source here:

• MAX_ORIG_NEWLINES=0 jindraivanek@3eeafcc
• MAX_ORIG_NEWLINES=1 jindraivanek@1fdbc65
• MAX_ORIG_NEWLINES=2 no change

[nojaf]

Well, this solves a part of the problem. Perhaps different node type are not that much harder.
If we do something different for SynModuleDecl and SynModuleSigDecl that might be good enough to start with.

Fantomas would still not do the right thing in terms of adding the right amount of blank lines if the user didn't do this correctly.
Imagine printing code from AST for example. Maybe that is acceptable for now. We never really have gotten any request in Fantomas of users asking for more newlines.

[jindraivanek]

Well, this solves a part of the problem. Perhaps different node type are not that much harder. If we do something different for SynModuleDecl and SynModuleSigDecl that might be good enough to start with.

Maybe. We can start with global option, and someone interested enough in that feature could extend it to multiple options.

Fantomas would still not do the right thing in terms of adding the right amount of blank lines if the user didn't do this correctly. Imagine printing code from AST for example. Maybe that is acceptable for now. We never really have gotten any request in Fantomas of users asking for more newlines.

I agree, there is some places, where I would like to see more newlines. But I think it's separate issue, these two areas don't depend on each other.