Change:
fontInfo: register(new EditorFontInfo()), fontLigatures2: register(new EditorFontLigatures()), fontSize: register(new EditorFontSize()), <del> fontWeight: register(new EditorStringOption( EditorOption.fontWeight, 'fontWeight', EDITOR_FONT_DEFAULTS.fontWeight, { enum: ['normal', 'bold', '100', '200', '300', '400', '500', '600', '700', '800', '900'], description: nls.localize('fontWeight', "Controls the font weight.") } )), </del> <ins> fontWeight: register(new EditorFontWeight()), </ins> formatOnPaste: register(new EditorBooleanOption( EditorOption.formatOnPaste, 'formatOnPaste', false, { description: nls.localize('formatOnPaste', "Controls whether the editor should automatically format the pasted content. A formatter must be available and the formatter should be able to format a range in a document.") }

Discussion:
Currently only accepts values from which is convenient to pick from dropdown, however causes problems with fonts when there is noticeable difference between e.g. , , and because is not valid value. Recently was released which provide nicer look for value but marked as invalid. I propose to allow numeric values in addition to current enum values (for backward compatibility) accordind to Draft PR: If this request will be approved - I'll add same support to and options. Only drawback that I see at this point - it's no longer possible to pick value from dropdown in Settings editor, however text values are still suggested in JSON. UPD. As alternative it would be nice to have at least values at the end of the list of values
any chance to get feedback on this issue? Looks like I'm not the only one with similar request -
I will try to set some time aside in August. I didn't look at it because the PR is marked as a draft. I thought that a "draft PR" represents work-in-progress and is not ready for review.
it was marked as draft for 2 reasons: 1) There was no approve on this issue yet, if proposed solution will be considered and mentioned cons aren't blocker for this feature. 2) If approved - I was going to do same for terminal . Since it's not rejected at this point I can finish changes for terminal and move PR out of draft status. UPD. Implementation for is ready at this point.
It seems to accept 350 (as number) or any other number but I think it is very bogous that "300" (as string) is accepted but not "350". There is also no hit in the hover info that a string-enum and any number is OK.
Previously allowed string values etc. are left as is so users won't have problems with their existing settings (ideally there would be great to have something as migration scripts and replace it with as number and don't allow ). (as string) was never allowed before (worked but was a warning) therefore I don't see it as problem. I can check if it's or and treat it as number otherwise if necessary, however not sure how pattern validation will work in this case. Agree with hint.

I guess that text like should do the trick
OK, I guess combination of , , and + + will provide good experience - suggests values from existing enum, allows , and has adequate error message for strings like and . Will submit PR later today. Any suggestions on how to improve are welcome.
I like that. Thanks