Code Actions do not respect formatting options

[rmunn]

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-preview3-004056)

Product Information:
 Version:            1.0.0-preview3-004056
 Commit SHA-1 hash:  ccc4968bc3

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  14.04
 OS Platform: Linux
 RID:         ubuntu.14.04-x64

VS Code version: 1.9.0
C# Extension version: 1.6.2

Contents of omnisharp.json in root directory of my current project:

{
    "formattingOptions": {
        "useTabs": true
    }
}

Steps to reproduce

1. Open a file that contains tab indentation.
2. Type in a function name that doesn't exist, like DoSomething();
3. Select the "Generate method" quick fix.

Expected behavior

OmniSharp generates a method matching the indentation of the current file:

Actual behavior

The method is generated with spaces, even though the file is indented with tabs (which VS Code was able to auto-detect) and the omnisharp.json config file specified using tab indentation:

Any new lines of code that I write in the file, though, will contain tab indentation since VS Code has (correctly) detected that the file contains tabs. (I actually prefer spaces for indentation myself, but the project's coding standards require tabs, so that's what I'm using for this project).

Workaround

I can work around this by selecting the newly-created method, hitting Shift-Tab once to dedent it (which causes VS Code to convert its indentation to spaces), then hitting Tab once to indent it again, which adds a tab as it moves back to its original indentation. But I'd rather see OmniSharp detect the current indentation style of the file and match it -- or, failing that, at least respect the omnisharp.json settings.

Related bugs

The part where I say "I'd rather see OmniSharp detect the current indentation style of the file and match it" might be a completely new feature request, but the part where the omnisharp.json settings file seems to be ignored looks like it might be a regression of #834 and/or #927. Also, PR #1055 might be related.

[filipw]

Thanks for the report - this is indeed a bug, but it is not a regression.
The other bugs you listed were dealing with document formatting using Omnisharp's code format endpoints, rather than applying code actions (which is the case here) - for example mangle up some code, right click, select Format Document - your tab settings should be used.

OmniSharp will absolutely try to detect your VS Code settings and apply accordingly, even without omnisharp.json (although the JSON file is given higher priority indeed).

Can you also list your settings for (unless you use defaults):

• omnisharp.useEditorFormattingSettings
• editor.insertSpaces
• editor.detectIndentation

[rmunn]

All three of those are set to the default values (true, true and true) for me. I haven't changed them in either my user settings, my workspace settings, or my omnisharp.json file.

[DustinCampbell]

It looks to me like OmniSharp never sets the formatting options on its workspace, so features never automatically (like code actions) pick them up.

[filipw]

Yes that's exactly what's happening.

I'm thinking the best/most flexible way to go forward would be to create a MEF extensibility point in Omnisharp.Abstractions that would allow different components such as Omnisharp.Roslyn.CSharpand perhaps in the future, loaded plugins too, to modify the workspace prior to it being initialized (similar to how project systems are discovered https://github.com/OmniSharp/omnisharp-roslyn/blob/dev/src/OmniSharp.Host/Startup.cs#L183-L199). This way we get a hook to set the formatting settings and other global workspace things early on.

This would also simplify a lot of code, as at the moment the formatting endpoints keep creating the formatting settings over and over too.

[DustinCampbell]

This issue was moved to OmniSharp/omnisharp-roslyn#759

[DustinCampbell]

Since all of the work will need to happen in omnisharp-roslyn, let's track it there.