VS Code User/Workspace Settings

[CoverRyan]

Overview

Extensions in VS Code can expose settings to the user by adding them to contributes.configuration section in the package.json. The user can then modify these configuration options in the Settings editor or by editing the settings.json file directly. More information on this can be found here.

Currently, the extension exposes various settings in the User/Workplace settings and any modifications to these settings changes the default value used in the extension. For example, changing the data file selection setting from ${command:AskForDataName} will result in the launch configuration defaulting to the new value, and the user will most likely not know what to enter to return it back to the original functionality. This concern was brought up in this issue. Below are 3 approaches to addressing this concern.

Solution 1: Add Documentation

Exposing the configurations in the User/Workplace settings is a feature that allows the user to change the default values used by the extension. This can be beneficial to the user especially if they have to constantly change the default value to another value in the launch configuration. For example, if they need the debug server or the data editor to run on a different port, they could modify this in the User/Workplace settings, and they wouldn't have to change it every time they configure the launch.json.

To address the concern, we would add documentation to the wiki explaining how to get to the User/Workplace settings, how they can be modified to change the default value, give descriptions of the settings exposed there, and provide the original default values.

Solution 2: Remove these Settings from the User/Workplace Settings

To address the concern, we could remove these settings from the package.json so they are not exposed to the user. This eliminates the possibility of the user changing settings and possibly breaking the extension and not knowing how to revert it back. The default values for all the setting being removed would need to handle elsewhere, most likely in the source code. Refactoring the launch configuration code may be necessary with this approach.

Solution 3: Remove Some Settings from the User/Workplace Settings

To address the concern, we could do a mix of Solution 1 and 2. We remove some of the settings that we don't think the user should be able to change but keep the ones that might be beneficial for the user and add documentation for those settings.

[lrbarber]

This is also related to apache#64
I believe there was some discussion about changing the names of some settings to include dfdl prefix o differentiate them from global settings that might be used elsewhere but have the same name and user changes intended for the other use might adversely have an effect on us.