Change Details

**Background** See T418352 for discussion that prompted this. In particular, many users will want different preferences for wikitext versus non-wikitext, but conceivably desire could go beyond that to specific content models/languages. I don't personally think the namespace-based preferences make much sense, and unless we see a use case for it, I'll refrain from including them. If we only allow preferences to differ based on content model, we can use integers to reference the constants in `Hooks::SUPPORTED_MODES`. 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). 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, it should only apply to other pages with the same content model. * "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`.

**Background** See T418352 for discussion that prompted this. In particular, many users will want different preferences for wikitext versus non-wikitext, but conceivably desire could go beyond that to specific content models/languages. I don't personally think the namespace-based preferences make much sense, and unless we see a use case for it, I'll refrain from including them. If we only allow preferences to differ based on content model, we can use integers to reference the constants in `Hooks::SUPPORTED_MODES`. 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). 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, it should only apply to other pages with the same content model. * "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`).

**Background** See T418352 for discussion that prompted this. In particular, many users will want different preferences for wikitext versus non-wikitext, but conceivably desire could go beyond that to specific content models/languages. I don't personally think the namespace-based preferences make much sense, and unless we see a use case for it, I'll refrain from including them. If we only allow preferences to differ based on content model, we can use integers to reference the constants in `Hooks::SUPPORTED_MODES`. 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). 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, it should only apply to other pages with the same content model. * "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`).