Background
See T418352 for discussion that prompted this.
In particular, many users will want different preferences for wikitext versus non-wikitext. Conceivably desire could go beyond that to specific content models/languages, but that would require a significant amount of code complexity, and worse, it could be more costly to storage. As for per-namespace granularity, I don't personally think doing this for preferences makes much sense, and unless we see a use case for it, I'll refrain from including it
If we only allow preferences to differ based on wikitext versus non-wikitext, we can use a four integer constants: (0) not enabled in any mode, (1) enabled in all modes, (2) wikitext mode only, and (3) non-wikitext modes only. This allows us to keep the storage footprint of the codemirror-preferences user option to a minimum (so it can continue to grow as we add more features). Furthermore, the 0 and 1 values are backwards-compatible with the current storage structure.
To keep things simple, for now we will carry on with only support for boolean preferences (i.e. the feature is on or off). Later that can be expanded, but will probably call for a new user option. See T408729 for example.
I'm assuming having a UI to manage all the content models of each preference is not necessary. We can instead just silently apply it as features are toggled.
Rough acceptance criteria
- When toggling a preference in wikitext, it should only apply to wikitext and no other modes/languages.
- Likewise when toggling a preference in non-wikitext, it effects all modes except wikitext.
- "Reset to defaults" can be reworked if we want, i.e. when editing a JS page, you could have "Reset to defaults for JavaScript pages" and "Reset all preferences to defaults". The exact wording and design is to be determined.
- Preferences for any given feature should only be saved to the codemirror-preferences user option if they differ from the default (as defined by $wgCodeMirrorDefaultPreferences).