Change Details

We've made some small changes to the bracket matching plugin. These need to be upstreamed, or we need to rename the plugin and call it our own. CSS changes should probably be pushed out to the MediaWiki-extension-CodeMirror, since they don't belong upstream. Accessible colors should be reverted (due to invalidation during test). Error highlighting should be suppressed but by introducing a configuration flag. Our changes would ideally not make any difference to the behavior of the upstream library. Each feature, especially if it does make a behavioral change, needs to be isolated into its own patchset, ideally not dependent on any others. This makes it easier to submit patch requests and discuss orthogonally. "Renaming" would be a fallback strategy. If we're unable to upstream all of our changes, then we need to visibly fork the plugin, e.g. "brackets-wmde.js", and include self-documentation explaining when and how we forked. This is necessary so that the people responsible for the future CodeMirror 6 upgrade aren't taken by surprise, and accidentally miss our customizations during the migration. (Note: T270317 and this ticket partly overlap.) To do: [x] Document our customizations. Done via T270317. [x] Rename our customized version. Done: https://gerrit.wikimedia.org/r/656103 [x] Check which of our changes we can upstream. [x] Introduce a config flag to disable the error highlighting. Done: https://github.com/codemirror/CodeMirror/pull/6565 [x] We "fixed" a compatibility issue between matchbrackets addon and mediawiki mode by disabling a feature. Can we find a generic solution that works for everybody? Is it worth our time? [x] We scan for pairs even if the cursor is not on a bracket. While it would be possible to submit this upstream, it's a new feature that would dramatically change what the addon does. It would need to be disabled by default. The cost to create a patch and maintain this feature (being the only user) is probably not worth it. Let's live with the fact that we have a fork. [x] Reverting the accessibility colors is not necessary. This was exclusively on GitLab.

We've made some small changes to the bracket matching plugin. These need to be upstreamed, or we need to rename the plugin and call it our own. CSS changes should probably be pushed out to the MediaWiki-extension-CodeMirror, since they don't belong upstream. Accessible colors should be reverted (due to invalidation during test). Error highlighting should be suppressed but by introducing a configuration flag. Our changes would ideally not make any difference to the behavior of the upstream library. Each feature, especially if it does make a behavioral change, needs to be isolated into its own patchset, ideally not dependent on any others. This makes it easier to submit patch requests and discuss orthogonally. "Renaming" would be a fallback strategy. If we're unable to upstream all of our changes, then we need to visibly fork the plugin, e.g. "brackets-wmde.js", and include self-documentation explaining when and how we forked. This is necessary so that the people responsible for the future CodeMirror 6 upgrade aren't taken by surprise, and accidentally miss our customizations during the migration. (Note: T270317 and this ticket partly overlap.) To do: [x] Document our customizations. Done via T270317. [x] Rename our customized version. Done: https://gerrit.wikimedia.org/r/656103 [x] Check which of our changes we can upstream. [x] Introduce a config flag to disable the error highlighting. Done: https://github.com/codemirror/CodeMirror/pull/6565 [x] We "fixed" a compatibility issue between matchbrackets addon and mediawiki mode by disabling a feature. Can we find a generic solution that works for everybody? Done: https://github.com/codemirror/CodeMirror/pull/6572 [x] We scan for pairs even if the cursor is not on a bracket. While it would be possible to submit this upstream, it's a new feature that would dramatically change what the addon does. It would need to be disabled by default. The cost to create a patch and maintain this feature (being the only user) is probably not worth it. Let's live with the fact that we have a fork. [x] Reverting the accessibility colors is not necessary. This was exclusively on GitLab.

We've made some small changes to the bracket matching plugin. These need to be upstreamed, or we need to rename the plugin and call it our own. CSS changes should probably be pushed out to the MediaWiki-extension-CodeMirror, since they don't belong upstream. Accessible colors should be reverted (due to invalidation during test). Error highlighting should be suppressed but by introducing a configuration flag. Our changes would ideally not make any difference to the behavior of the upstream library. Each feature, especially if it does make a behavioral change, needs to be isolated into its own patchset, ideally not dependent on any others. This makes it easier to submit patch requests and discuss orthogonally. "Renaming" would be a fallback strategy. If we're unable to upstream all of our changes, then we need to visibly fork the plugin, e.g. "brackets-wmde.js", and include self-documentation explaining when and how we forked. This is necessary so that the people responsible for the future CodeMirror 6 upgrade aren't taken by surprise, and accidentally miss our customizations during the migration. (Note: T270317 and this ticket partly overlap.) To do: [x] Document our customizations. Done via T270317. [x] Rename our customized version. Done: https://gerrit.wikimedia.org/r/656103 [x] Check which of our changes we can upstream. [x] Introduce a config flag to disable the error highlighting. Done: https://github.com/codemirror/CodeMirror/pull/6565 [x] We "fixed" a compatibility issue between matchbrackets addon and mediawiki mode by disabling a feature. Can we find a generic solution that works for everybody? Is it worth our time?Done: https://github.com/codemirror/CodeMirror/pull/6572 [x] We scan for pairs even if the cursor is not on a bracket. While it would be possible to submit this upstream, it's a new feature that would dramatically change what the addon does. It would need to be disabled by default. The cost to create a patch and maintain this feature (being the only user) is probably not worth it. Let's live with the fact that we have a fork. [x] Reverting the accessibility colors is not necessary. This was exclusively on GitLab.