Store rules in settings.json

[daeh]

It would be great if rules were stored along with other vscode settings for a variety or reasons. To illustrate one, I use VS Code profiles. I set up global rules in one profile and I would like to copy them into other profiles, which would be easy if I could copy json from one settings file to another.

Thanks!

[stneveadomi]

I definitely am interested in supporting this, but I am less familiar with profiles. With different profiles, do the global rules persist across workspaces? (e.g. if you change from profile A to profile B, do the global rules in the workspace stay the same regardless of profile?)

The initial thought was to allow importing and exporting of rules, but if it will be easier to store this in settings and support profiles, this may be easier.

Additionally, we could add a third dropdown so we would have the following:

• Workspace specific rules
• Global specific rules
• Profile specific rules

And then drag and drop between them would be supported, as well as, allowing import and export of this rules.

[daeh]

Currently global rules do not persist across profiles.

I don't think that's inherently a problem; profiles are supposed to be largely independent of each other. But there's currently no way to copy rules from one profile to another.

I think there are multiple advantages to having the config stored as json in settings.json. Most plugins opt for that config strategy and I'm guessing that it makes sense here too.

Each profile has it's own settings.json. I think that if the rules is stored in settings.json you won't need to build any additional support for profiles. VSCode should make the rest of it work without additional work on your part. Users will just be able to copy the json from one profile to another in order to duplicate rules (and this would be done automatically if a user make a new profile by duplicating an existing one).

In other words, the expected behavior would be that:

• Global rules apply to all workspaces with a given profile.
• Different profiles will have different global rules.

And that should all work out of the box if the plugin stores rules in the User's settings.json.

[stneveadomi]

@daeh I know this wasn't exactly the ask of this issue, but I am interested in your thoughts.

See attached video.

The main reason I avoided storing the rules in the settings.json is because of how verbose the data is and how it is currently stored.

Happy to hear community feedback from this.

Here is the export feature, it shoves it into your clipboard.

[daeh]

Cool improvements. I won't have a time to play with it until after some deadlines. But just to quickly share first impressions while the idea are up:

• 1. Thanks for the work on this. The ability to backup the settings, and to copy and paste from one profile to another, are major usability improvements.
• 2. It's so standard for plugins to store config settings in settings.json, I would think that deviating form that norm would be a last resort and only when absolutely necessary. I use several plugins that add sizable chunks to settings.json. I'm use to it, expect it, and VS Code makes it easy to deal with (e.g. w/ code folding).
• 3. If you didn't include the keys for settings with unset and default values, the data stored in the settings.json would not even be that extensive. And if someone is really configuring all of those options, they're going to be ok with having that level of specification stored in their settings.json.

So great progress on this. And I'd still strongly advocate for have the config stored in settings.json, which is a strong convention for VS Code plugins.

Will add more thoughts after I have a chance to try things out!

[stneveadomi]

Hey @daeh, good point, and I think these features aren't mutually exclusive (the settings.json and the dev edit mode).

For that reason, I have reopened this issue as I do see it as a potentially valuable feature to implement.

I do need to clean up the storage, so perhaps I can focus on this more soon. For the meantime, the previous PR should unblock those flows.

Thank you for the context on the large plugin storage. That's good to know. I will need to explore the data storage design and evaluate settings.json vs VSCode extension storage options

Context, for those interested: https://code.visualstudio.com/api/extension-capabilities/common-capabilities#data-storage

[stneveadomi]

So I laid out the architecture a bit more clearly, and I believe this demonstrates my hesitation with implementation.

The global rules can be overridden by a workspace-specific settings.json change, and from the extension perspective, we have no way of knowing which settings.json is a User specific or a workspace specific.

Now this still leaves us with the option of having a hybrid of the two approaches, where only the workspace rules are stored in the settings.json. However, I am not sure if we can even support propagating changes from the extension to the settings.json (let's say we change a rule, how do we know where to update settings.json?) We could potentially make read-only rules, but as you can see, the complexity increases.

[stneveadomi]

As of right now, marking this issue as a won't fix until a more compelling reason / solution comes up.

I am still happy to discuss this, but as of right now, I believe the use case is supported and settings.json was not designed for dynamic data.

Happy to hear more ideas and for that I will keep this issue open.

@daeh let me know if you end up with any other thoughts on this.

[daeh]

Appreciate the thought you've put into it, @stneveadomi. I'll reopen if anything new comes up. The ability to backup rules and copy them between profiles is a huge improvement.

No need to respond to this point, but I figured I'd just mention that the regex highlighter I was using before switching to grepc stored it's config in the setting.json, and it basically worked like I expected from a purely user-experience perspective, which is why I was accustomed to working with them across projects and profiles in that way. I'm not sure if grepc is set up that makes the settings.json approach more complicated, but just as a point of reference, this is the type of thing would be stored in settings.json by the other plugin.

Thanks again for these big improvements and detailed explainations!

{
  "highlight.regex.regexes": [
    {
      "languageIds": ["python", "julia", "jsonc"],
      "regexes": [
        {
          "regex": "(empir)",
          "regexFlag": "gmi",
          "regexLimit": 25000,
          "decorations": [
            {
              "index": 1, // index match regex group
              "fontWeight": "bold",
              "borderRadius": "4px",
              "dark": {
                "border": "2px dotted rgb(0, 242, 255, .8)"
              },
              "overviewRulerLane": 4
            }
          ]
        },
        {
          "regex": "[^@](model)",
          "regexFlag": "gmi",
          "regexLimit": 25000,
          "decorations": [
            {
              "index": 1, // index match regex group
              "fontWeight": "bold",
              "borderRadius": "4px",
              "dark": {
                "border": "2px dotted rgb(200, 0, 255, 0.8)"
              },
              "overviewRulerLane": 4
            }
          ]
        },
        {
          "regex": "(?:\\b|_)(train)(?:\\b|_|df|data)",
          "regexFlag": "gmi",
          "regexLimit": 25000,
          "decorations": [
            {
              "index": 1, // index match regex group
              "borderRadius": "4px",
              "dark": {
                "border": "2px solid rgb(0, 242, 255, .6)"
              },
              "overviewRulerLane": 4
            }
          ]
        },
        {
          "regex": "(?:\\b|_)(test)(?:\\b|_|df|data)",
          "regexFlag": "gmi",
          "regexLimit": 25000,
          "decorations": [
            {
              "index": 1, // index match regex group (TODO)
              "borderRadius": "4px",
              "dark": {
                "border": "2px solid rgb(200, 0, 255, .6)"
              },
              "overviewRulerLane": 4
            }
          ]
        }
      ]
    }
  ],
}

[stneveadomi]

@daeh Ah, I believe I am starting to see the issue. Those extensions do not offer an interface to customize the rules and thus do not suffer from the aforementioned issue of where to update settings.json (because they make the user do it!).

If you make the user write to settings.json, then they can update wherever they want! We do not have that luxury as with our interface, we allow users to change the rules in the interface, making the extension have to deal with writing back to the appropriate spot.

Another thought, to support a similar user experience, is to create a dropdown that is based on settings.json (Global Rules, Workspace Rules, and new Settings.json Rules). This settings.json dropdown would function similar to the way it works above, however, it would be read only. We could gray out all the inputs and simply allow enabling/disabling.

A way to support users working on this flow would be allowing the drag and drop to either a workspace or global rules and then it would become editable. You could drag and drop from settings.json to workspace/global, but not vice versa.

Just some thoughts.