Workaround Roslyn formatting bug

[333fred]

Due to dotnet/roslyn#50129, FormatAsync will give us changes past the location that we wanted if there were changes to be made on the current line. This can lead to a frustrating typing experience now that we listen for \n in vscode to trigger formatting. I've implemented a simple workaround for this while the bug is fixed upstream.

[333fred]

I'm not sure there's a good way to work around this one until the upstream bug is fixed.

[333fred]

@JoeRobich @filipw so in talking with Cyrus, he pointed out a few things:

1. Roslyn doesn't even support this type of after-character formatting. Indeed, the editor features on-type formatting supports ;{}#nte:): http://sourceroslyn.io/#Microsoft.CodeAnalysis.CSharp.EditorFeatures/Formatting/CSharpEditorFormattingService.cs,38.
2. Further, we (roslyn) could consider moving IEditorFormattingService down to the features layer and O# can depend on that, rather than calling format ourselves and likely not passing in the correct options (for paste formatting or return formatting or whatever else).

Given those points, should we even be attempting to format on newlines at all (other than the doc comment feature)? Seems like we're trying to use a roslyn feature in a way it wasn't really intended to be used, and hitting issues because of it.

[filipw]

thanks for the background info, I now understand the problem better. I like your suggestion to move IEditorFormattingService to features layer, even if it wasn't public we could easily start using it which would be the most optimal solution

[333fred]

And did you have an opinion on the format-on-newline bit?

[filipw]

yes I would say for me it is acceptable for OmniSharp to only support this in targeted scenarios - like doc comments - and not have this everywhere.

[333fred]

Submitted #2053 to remove the support entirely.