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

Fix #199 - Explicitly set custom F# editor settings if they are missing #491

Closed
wants to merge 4 commits into from

Conversation

latkin
Copy link
Contributor

@latkin latkin commented Jun 9, 2015

After talking with VS platform people, this is the suggested workaround for cases where VS fails to apply the custom F# settings from the General profile.

F# only specifies 3 (edit: 4) settings that deviate from the editor defaults, so it's only these 3 that need special care, AFAICT.

I'm still talking with the platform people to make sure this is the correct approach, but figured I'd send the PR to get review early.

ref #199

On package load, check if any of the custom F# settings are somehow missing
from the settings store.  Explicitly set them to their desired defaults if
they are indeed missing.

I've added this to the language service package since this is guaranteed
to load any time the project system package is loaded, but the converse is
not true (e.g. open loose F# script file without opening a solution).

fixes dotnet#199
// If cloud-synced settings have already been applied or the user has made an explicit change, do nothing
match settingsManager.TryGetValue(settingName) with
| Microsoft.VisualStudio.Settings.GetValueResult.Missing, _ ->
settingsManager.SetValueAsync(settingName, defaultValue, false) |> ignore
Copy link
Contributor

Choose a reason for hiding this comment

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

SetValueAsync return a Task, await the task completion instead of ignore?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There is not much use in awaiting this. It is a plain Task, there is no return value to inspect. Even if it fails, there is no particular retry or error handling we would implement. In theory if settingsManager falls out of scope and gets GCed it might cancel its child tasks or something, but practically speaking this won't happen for a shared VS service.

On the Roslyn side they take a similar approach of fire and forget.

@latkin
Copy link
Contributor Author

latkin commented Jun 10, 2015

/cc @jasonmalinowski for review of IDE stuff

@MattGertz
Copy link

Approved 6/10 by ML Shiproom.

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.

5 participants