Better Handling of Settings Sections

[colin-grant-work]

Feature Description:

At the moment we use the same classes to handle JSON files for all of our settings sections (settings, tasks, launch), and all of them can be reached using the .set and .get methods of the PreferenceService. As a consequence, we've introduced logic that analysis the preference name string fed to those methods and directs the call to the appropriate file handler. For example:

theia/packages/preferences/src/browser/folders-preferences-provider.ts

Lines 135 to 137 in eb83e0e

	async setPreference(preferenceName: string, value: any, resourceUri?: string): Promise<boolean> {
	const sectionName = preferenceName.split('.', 1)[0];
	const configName = this.configurations.isSectionName(sectionName) ? sectionName : this.configurations.getConfigName();

theia/packages/preferences/src/browser/user-configs-preference-provider.ts

Lines 93 to 95 in eb83e0e

	async setPreference(preferenceName: string, value: any, resourceUri?: string): Promise<boolean> {
	const sectionName = preferenceName.split('.', 1)[0];
	const configName = this.configurations.isSectionName(sectionName) ? sectionName : this.configurations.getConfigName();

theia/packages/preferences/src/browser/workspace-file-preference-provider.ts

Lines 67 to 69 in eb83e0e

	protected getPath(preferenceName: string): string[] {
	const firstSegment = preferenceName.split('.')[0];
	if (firstSegment && this.configurations.isSectionName(firstSegment)) {

theia/packages/preferences/src/browser/section-preference-provider.ts

Lines 71 to 81 in eb83e0e

	protected getPath(preferenceName: string): string[] | undefined {
	if (!this.isSection) {
	return super.getPath(preferenceName);
	}
	if (preferenceName === this.section) {
	return [];
	}
	if (preferenceName.startsWith(`${this.section}.`)) {
	return [preferenceName.slice(this.section.length + 1)];
	}
	return undefined;

One consequence of this approach is that we cannot easily handle preferences (that belong in settings.json) with the same prefix as a section. For tasks and launch, that isn't generally a problem because the prefix for settings is different from the file name: task rather than tasks, debug rather than launch. However, VSCode also supports an extensions.json file and several preferences with the prefix extensions, and our system cannot correctly handle those settings. If we support extensions.json, then extensions.ignoreRecommendations will be treated as the ignoreRecommendations field of the object in extensions.json rather than the extensions.ignoreRecommendations key of the object in settings.json.

The cleanest solution would be to modify our .set and .get methods to include the section name as an explicit argument (defaulting to settings) or to introduce alternative .getFromSection and .setInSection methods that would include such an argument. If those were used across the board, we could also dispense with some of the logic (dangerously) extracting the section name from the single preference name argument.