1. Don't parse/validate the option in editorOptions.ts

Editor options can be a bit tricky because each editor instance can be configured differently. e.g. it would be possible to have an editor with word wrap enabled while another one with word wrap not enabled. That is the reason why all these editorOptions.ts classes/interfaces exist. This is typically done by having someone on the outside reading the IConfigurationService and applying it partly or fully to an editor instance, and then all the code in the editor goes through these editorOptions.ts interfaces to read the effective setting.

However, in this case, this new option is not editor instance specific. This can be spotted by the reading side, in TMSyntax.ts, where reading is done through the IConfigurationService directly (a singleton). So, I suggest we remove all the additions from editorOptions.ts. It is still possible to have an option editor.something and for it to not be parsed/validated/etc. in editorOptions.ts if it is being read straight through the IConfigurationService.

2. Find a better name

I think editor.longLineLength is too fuzzy. For example, we have another built-in constant for rendering lines. Lines longer than 10k chars will be painted with a '...' in the view (again to prevent freezes). If we were to make that configurable we would have a name clash. I therefore suggest we come up with a better name here, something that contains one of the following (or a synonym if you have a better one): tokenization, grammars, colorization, syntax highlighting.

See comments