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

Correctly set formatting options on the workspace #770

Merged
merged 8 commits into from
Feb 13, 2017

Conversation

filipw
Copy link
Member

@filipw filipw commented Feb 12, 2017

fixes #759

This PR changes our approach to CSharp formatting options. So far, we'd use the OmniSharp workspace without paying any attention to formatting settings - those were always applied on demand via each of the formatting endpoints. As a result, any formatting change that happened differently than through those endpoints (i.e. running code actions) would not respect the settings.

The change here is to introduce a discoverable provider, IWorkspaceOptionsProvider (maybe anyone can suggest a better name?) which is discovered at app startup and provides the workspace with formatting options. In our case, the only provider at the moment would be CSharpWorkspaceOptionsProvider but in the future we could easily add more, or have different ones loaded via the plugin infrastructure, so from that perspective we are also introducing a new extensibility point into OmniSharp.

Copy link
Member

@david-driscoll david-driscoll left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I got lost at first trying to figure out where the options were getting set, but then I came to my senses and found it.

@david-driscoll
Copy link
Member

At least once CI passes... :)

{
try
{
Workspace.Options = workspaceOptionsProvider.Process(Workspace.Options);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This implies an order to the IWorkspaceOptionsProviders. Is there a way we can define that?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to avoid getting into that yet, because that would need a more generic solution anyway - for the plugins.
I believe the best approach would be to use MEF metadata something like:

    public interface IPlugin
    {
        string Name { get; }
        int Order { get; }
    }

    [MetadataAttribute]
    public class PluginMetadataAttribute : ExportAttribute, IPluginMetadata
    {
        public string Name { get; set; }
        public int Order { get; set; }

        public PluginMetadataAttribute()
            : base(typeof(IPlugin))
        {
        }
    }

[PluginMetadata(Name = "DefaultCSharpFormatting", Order = -1)]

And then use this metadata when plugins are discovered; this would apply to all plugins in the future. However, I believe we would need to design it a bit more carefully - I'll open a separate issue to track that

}
catch (Exception e)
{
var message = $"The workspace optiosn provider '{workspaceOptionsProvider.GetType().Name}' threw exception during initialization.";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be helpful to see the workspaceOptionsProvider.GetType().FullName here.

@@ -69,6 +71,10 @@ protected Task<OmniSharpWorkspace> CreateWorkspaceAsync(params TestFile[] testFi

var workspace = plugInHost.GetExport<OmniSharpWorkspace>();

// OmniSharp ships only one provider, CSharpWorkspaceOptionsProvider
var formattingProvider = plugInHost.GetExports<IWorkspaceOptionsProvider>().FirstOrDefault() as CSharpWorkspaceOptionsProvider;
Copy link
Contributor

@DustinCampbell DustinCampbell Feb 13, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the comment, would Single() be a better choice for tests?

@@ -69,6 +71,10 @@ protected Task<OmniSharpWorkspace> CreateWorkspaceAsync(params TestFile[] testFi

var workspace = plugInHost.GetExport<OmniSharpWorkspace>();

// OmniSharp ships only one provider, CSharpWorkspaceOptionsProvider
var formattingProvider = plugInHost.GetExports<IWorkspaceOptionsProvider>().FirstOrDefault() as CSharpWorkspaceOptionsProvider;
workspace.Options = formattingProvider?.Process(workspace.Options);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As written, if the CSharpWorkspaceOptionsProvider isn't included in the MEF composition, this will set workspace.Options to null. Intentional?

{
public interface IWorkspaceOptionsProvider
{
OptionSet Process(OptionSet workOptionSet);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did a bit of a double-take when I read workOptionSet. I wasn't sure if this meant "working option set" or "workspace option set". Maybe just optionSet to avoid confusion?

@DustinCampbell
Copy link
Contributor

All of the CI failed with Error: /Users/travis/build/OmniSharp/omnisharp-roslyn/.tools/xunit.runner.console/tools/xunit.runner.utility.desktop.dll does not exist.

It looks like there was an update to xunit.runner.console. I bet that broke it.

@DustinCampbell
Copy link
Contributor

Yup. performing a git clean -xdf and then building fails. I'll get a fix out and then we can rebase this PR.

Copy link
Contributor

@DustinCampbell DustinCampbell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

None of my comments are blocking, though some of them are things we should think about (especially the ordering thing).

@DustinCampbell
Copy link
Contributor

PR is out to fix build: #772.

@DustinCampbell
Copy link
Contributor

There we go. 😄

@filipw
Copy link
Member Author

filipw commented Feb 13, 2017

PR is out to fix build: #772.

thanks! I didn't notice it - it worked when I ran the tests from VS 👍

@filipw filipw force-pushed the feature/workspace-formatting branch from 5df32d0 to 26b7e72 Compare February 13, 2017 08:19
@filipw
Copy link
Member Author

filipw commented Feb 13, 2017

None of my comments are blocking, though some of them are things we should think about (especially the ordering thing).

thanks for the feedback - I pushed the smaller things into this branch and spun off #773 specifically as part of the plugin infrastructure

@DustinCampbell DustinCampbell merged commit 6b8f215 into OmniSharp:dev Feb 13, 2017
@DustinCampbell
Copy link
Contributor

:shipit:

@DustinCampbell
Copy link
Contributor

thanks! I didn't notice it - it worked when I ran the tests from VS 👍

Tests run for you in VS? I haven't been able to get tests to run in VS since moving OmniSharp to netcoreapp1.1.

@filipw filipw deleted the feature/workspace-formatting branch February 13, 2017 16:34
@filipw
Copy link
Member Author

filipw commented Feb 13, 2017

They do, but only when netcoreapp1.1 is defined before net46 in the frameworks section of the project file.

screenshot 2017-02-13 21 22 24

@DustinCampbell
Copy link
Contributor

Ahhhh.... We should change that then.

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

Successfully merging this pull request may close these issues.

3 participants