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

Improve Plugin Preference Access #11393

Conversation

colin-grant-work
Copy link
Contributor

What it does

Fixes #10004
Depends on #11331
This PR updates various aspects of preference access and setting from plugins.

  • Adjusts PreferenceRegistry to use Monaco code for Configuration and ConfiguratioModel.
  • Enables access and setting of language-overridden preferences from plugins according to VSCode API (Introduce Type ConfigurationScope #10004)
  • Updates affectsConfiguration check to respect override options (language and URI)

How to test

  1. Assert that the tests pass - most of the functionality related to preference access and affectsConfiguration has new tests.
  2. Install this plugin (source)
  3. Open a single-root workspace.
  4. Run the command Listen for config changes
  5. Add and remove tasks, observe that a toast informs you that you have done so.
  6. Delete your tasks.json file.
  7. Observe that a toast registers for changes to tasks and tasks.tasks

On master, the deletion of the file would not be registered by plugins as a change in the section.

  1. Modify the value of editor.fontSize in your workspace; modify it for language overrides, including [rust]
  2. Observe that your changes are accurately reported.
  3. Clear the values of editor.fontSize in your workspace.

Run the command 'Stop listening for config changes' now if you want to see fewer toasts in the next step.

  1. Run the command 'Run config test (no language override)'
  2. It should modify the value for editor.fontSize in your workspace and report that the effective value has changed for non-overridden and for rust.
  3. Run the command 'Run config test (with language override)'
  4. Same as 10., but with different numerical values.
  5. Run the command 'Run config test (with forced language override)'
  6. It should create an overridden value for editor.fontSize for the rust language, and the report should show that only rust and not un-overridden editor.fontSize was affected
  7. Run the command 'Run config test (with language override)' again.
  8. This time, because an override already exists for rust after (13), you should see a toast similar to 14 - only the value for rust should be modified.

Review checklist

Reminder for reviewers

@colin-grant-work colin-grant-work added preferences issues related to preferences plug-in system issues related to the plug-in system labels Jul 7, 2022
@colin-grant-work
Copy link
Contributor Author

@tsmaeder, in the past, I believe you expressed concern about using Monaco code in the plugin host. This PR does so: it uses the Monaco versions of Configuration and ConfigurationModel rather than versions that we had copied when the plugin system was first written. Those classes reside in common folders of Monaco and they, or extensions of them, are also used in the VSCode plugin host. Do you believe that this use is reasonable, or that we should avoid importing directly from Monaco and copy / reimplement these classes?

@tsmaeder
Copy link
Contributor

tsmaeder commented Jul 8, 2022

@colin-grant-work like all interesting questions, this one does not have a straightforward answer. I don't mind having VS Code stuff in the plugin host per se. The problem is that as we use more code outside the editor proper, the larger the change becomes when we uplift Monaco to a new version. The reason this is more of a problem with Monaco than with other libraries is that we have to update all Monaco modules at the same time. Is this the direction we want to move the code in? The upside is that we can reuse stuff from VS Code.
As for this PR, I would propose to keep the copied classes unless that's a problem. Now that we have more experience with the improved uplift procedures (with the new way we consume VS Code modules), we should discuss whether we think it's proper to use stuff from VS code in our code base more broadly with the community. If we do, the two classes can be easily nuked in a follow-up PR.

Copy link
Contributor

@tsmaeder tsmaeder left a comment

Choose a reason for hiding this comment

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

Just some comments after a superficial look at the change.

const globalValue = this.inspectInScope<T>(preferenceName, PreferenceScope.User, resourceUri);
const workspaceValue = this.inspectInScope<T>(preferenceName, PreferenceScope.Workspace, resourceUri);
const workspaceFolderValue = this.inspectInScope<T>(preferenceName, PreferenceScope.Folder, resourceUri);
inspect<T>(preferenceName: string, resourceUri?: string, forceLanguageOverride?: boolean): PreferenceInspection<T> | undefined {
Copy link
Contributor

Choose a reason for hiding this comment

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

The name forceLanguageOverride confused me a bit at first. What it means is "don't return the general value if the key is language specific", right? I haven't really thought of a good name, though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I could reverse the polarity and rename it something like acceptDefault. There's no exactly antonym for language overridden, though...

packages/monaco/README.md Outdated Show resolved Hide resolved
 - Adjusts PreferenceRegistry to use Monaco code for `Configuration` and `ConfiguratioModel`.
 - Enables access and setting of language-overridden preferences from plugins according to VSCode API
 - Updates `affectsConfiguration` check to respect override options (language and URI)
@colin-grant-work colin-grant-work force-pushed the bugfix/plugin-affects-check branch from 77b0fa6 to 15b4fe2 Compare July 12, 2022 23:47
@JonasHelming
Copy link
Contributor

@colin-grant-work Is this ready for a re-review?

@colin-grant-work
Copy link
Contributor Author

@JonasHelming, yes - I believe I have addressed Thomas' comments, apart from the naming, and that review did not check the functionality, as far as I'm aware.

@JonasHelming JonasHelming requested a review from tsmaeder July 29, 2022 14:27
@msujew msujew self-requested a review August 2, 2022 11:36
Copy link
Member

@msujew msujew left a comment

Choose a reason for hiding this comment

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

I'm happy with the changes, good job 👍

  • Language scoped preferences work as expected (i.e. doesn't bleed into the "normal" preferences, are applied correctly and instantly)
  • Adding a tasks.json and changes within are correctly transmitted to the plugin
  • Running the different plugin commands for (non)-language-override preferences works as expected

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
plug-in system issues related to the plug-in system preferences issues related to preferences
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Introduce Type ConfigurationScope
4 participants