editor: update monaco editor preferences

[vince-fugnitto]

What it does

The pull-request updates the editor-preferences following the monaco-upgrade which were incomplete and did not include the proper descriptions leading to end-users not having the full information in the ui (preferences-view) and in the auto-completion of the settings.json.

Note: a lot of these new preferences following the upgrade are not available in vscode and are pretty internal to the application when creating the monaco-editor with the different editor-options, and I'm not sure should be exposed to end-users.

How to test

• verify the preferences-ui now displays the proper descriptions for the commands
• verify when editing the settings.json that the there is auto-completion descriptions available.

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

Signed-off-by: vince-fugnitto vincent.fugnitto@ericsson.com

[colin-grant-work]

The changes look reasonable to me - maybe 'context menu' should be two words - but I think this raises the question of whether we want to consider all of these things to be preferences. We currently populate the options of editors from the editor preferences, but many of these are not VSCode preferences, and seem more like application-level implementation decisions than user preferences. I would be inclined to create something like a getMonacoEditorOptions() method that merges some object full of defaults with settings exposed to the user. That way, the relative contribution of each can be changed by adopters by adding more preferences, but we're not exposing a bunch of Monaco internals by default.

[vince-fugnitto]

The changes look reasonable to me - maybe 'context menu' should be two words - but I think this raises the question of whether we want to consider all of these things to be preferences. We currently populate the options of editors from the editor preferences, but many of these are not VSCode preferences, and seem more like application-level implementation decisions than user preferences. I would be inclined to create something like a 'getMonacoEditorOptions()` method that merges some object full of defaults with settings exposed to the user. That way, the relative contribution of each can be changed by adopters by adding more preferences, but we're not exposing a bunch of Monaco internals by default.

@colin-grant-work I completely agree, I don't think these are end-user preferences, and are only editor options for developers creating monaco-editors:

Note: a lot of these new preferences following the upgrade are not available in vscode and are pretty internal to the application when creating the monaco-editor with the different editor-options, and I'm not sure should be exposed to end-users.

cc @tsmaeder @RomanNikitenko

[tsmaeder]

@vince-fugnitto I agree some of the preferences are for the programmer, not the user. But some like 'diffEditor.wordWrap' make sense to me for a user to set.
As for this PR: it still makes the code better and if we turn some of the prefs into code-level options, we can reuse the descriptions as documentation. In any case, we should proceed with the PR.

@vince-fugnitto could you open an issue detailing the preferences that should really be options?

[RomanNikitenko]

As for this PR: it still makes the code better

+ 1 to merge the current changes, tested according to the How to test section - works well!

I would be inclined to create something like a getMonacoEditorOptions() method that merges some object full of defaults with settings exposed to the user. That way, the relative contribution of each can be changed by adopters by adding more preferences, but we're not exposing a bunch of Monaco internals by default.

Sounds good to me! 👍

[colin-grant-work]

In case anyone was still waiting for my vote, I agree with @tsmaeder and @RomanNikitenko that providing text is good, regardless of what we do next.