Add an option to format without regard to input line breaks

[kitbellew]

To avoid frequent discussions in code review requesting formatting changes in the code to induce scalafmt to produce different output, I would like to introduce an option to format input and ignore input newlines (except adjacent to comments).

Propose 4 options:

• flag not specified, produces current mixed approach of sometimes ignoring input line breaks and sometimes following them;
• option to keep line breaks as specified;
• two options to try and ignore line breaks, one for fewer lines and another for shorter lines; both are affected by config style, select chains bin pack and other similar options, not sure if they should supercede then)

As this requires a lot of changes, I'd like to consider this option as work-in-progress until all changes have been merged, and larger community had time to comment. It will not be subject to edition guards until the logic has been finalized and declared completed.

NB: Follow-on to #1560

[kitbellew]

@olafurpg @tanishiking @poslegm need recommendation on this proposal.

• is the approach meaningful to you in the first place?
• do the options proposed make sense?
• making the changes is complex and will take some time, they will likely benefit from people trying out and commenting; I would like to add the options with a (temporary) disclaimer, then work on a sequence of PRs, possibly over a couple of releases until the formatting changes have been completed; thoughts about that?

[poslegm]

is the approach meaningful to you in the first place?

Personally I don't need this changes. And I never heard feedback about scalafmt from my teammates with something like it. But right now I'm only speaking for myself, not for the best solution for everyone.

do the options proposed make sense?

I strongly prefer forcing users to multiline blocks every time. So my only wish for potential changes is the configuration flag to keep current behavior.

making the changes is complex and will take some time, they will likely benefit from people trying out and commenting; I would like to add the options with a (temporary) disclaimer, then work on a sequence of PRs, possibly over a couple of releases until the formatting changes have been completed; thoughts about that?

I am completely OK with splitting big changes into couple of small releases

[ekrich]

@kitbellew I am mostly aligning with the sentiments of @olafurpg in the series of comments in #1560

My first impression of scalafmt was just that I didn't want to worry about formatting at all and this is what I found when working on Scala Native. If you look a the Google Java rules, they are really draconian. I have seen similar for C++ with the order of private, public etc.

Scala gives a better approach with nested functions, and order can make the code more readable and tools can alphabetize the methods, functions etc. so they don't need to be that way in the actual code. This is a bit off base but may help with my philosophy.

There are a sort of good, okay and bad categories of code formatting and if automated and in the first two, all is good. Bad is when the code is harder to read but of course this is also subjective based on what you are used to.

I wish there were pretty much a no options approach except for maybe line length and a few other basic independent options.

Now that I am trying to maintain a scalafmt config and progress through upgrades to scalafmt it is pretty crazy the amount of diffs created and trying to minimize the diffs can be a big time sink.

I do see a need to allow code to not wrap during formatting if basic things like internal spacing and line length are ok. The reverse to inline code may also be desirable. The problem I see is that then both of these styles could be in the code base and then a reviewer could say "I like the compact style, or I like the block style" and thus you are back to custom formatting or spending allot of time playing with options.

Hope this is helpful.

[kitbellew]

Looks like it's done :)