Fix wrong Type- and JavaScript highlighting inherited from parent scheme #116
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As of IDE versions 2019.3.x, some TypeScript and JavaScript syntax elements were not highlighted correctly. The following elements inherited the colors from the "Darcula" parent scheme instead of the language defaults defined by Nord: - Global function - Global variable - Instance member function - Instance member variable These elements are now using explicitly defined colors instead to fix the highlighting. GH-115
This was referenced Feb 10, 2020
svengreb
approved these changes
Feb 11, 2020
arcticicestudio
deleted the
bugfix/gh-115-ts-js-syntax-highlight-inherit
branch
arcticicestudio
added a commit
that referenced
this pull request
Feb 11, 2020
The `parent_scheme` is set automatically when a custom editor color scheme is created based on one of the bundled themes, like e.g. "Darcula" when the IDE uses a dark theme or “Default“ in light mode. Anyway, the attribute is not required at all and has been removed. Moreover, to the time of this PR there's no real indicator in the "IntelliJ IDEA Community Edition" source code [1] that the attribute has any functionality but only documenting the code base of the custom theme [2]. Nevertheless, it is possible that the attribute affects the logic how editor color schemes handle the inheritance of colors from other syntax definitions or the "Language Defaults". There was an increasing amount of reported issues where syntax elements were highlighted with colors from the "Darcula" editor scheme instead of the ones defined by Nord although the values must have been derived from other syntax definitions. This might be caused by the `parent_scheme` attribute which was set to "Darcula". Therefore the attribute has now been removed to mitigate such behavior. Thanks to Tom1206 [3] for the idea of inspecting the attribute. See GH-115 for more details. [1]: https://github.com/JetBrains/intellij-community/search?p=2&q=parent_scheme&unscoped_q=parent_scheme [2]: https://github.com/JetBrains/intellij-community/blob/4491058316bab4162d2ee0a926ac65553b56e6a5/platform/editor-ui-ex/src/com/intellij/openapi/editor/colors/impl/AbstractColorsScheme.java#L311-L313 [3]: https://github.com/Tom1206 Related to GH-115, GH-116
svengreb
pushed a commit
that referenced
this pull request
Feb 11, 2020
As of IDE versions 2019.3.x, some TypeScript and JavaScript syntax elements were not highlighted correctly. The following elements inherited the colors from the "Darcula" parent scheme instead of the language defaults defined by Nord: - Global function - Global variable - Instance member function - Instance member variable These elements are now using explicitly defined colors instead to fix the highlighting. Fixes GH-115
svengreb
pushed a commit
that referenced
this pull request
Feb 11, 2020
The `parent_scheme` is set automatically when a custom editor color scheme is created based on one of the bundled themes, like e.g. "Darcula" when the IDE uses a dark theme or “Default“ in light mode. Anyway, the attribute is not required at all and has been removed. Moreover, to the time of this PR there's no real indicator in the "IntelliJ IDEA Community Edition" source code [1] that the attribute has any functionality but only documenting the code base of the custom theme [2]. Nevertheless, it is possible that the attribute affects the logic how editor color schemes handle the inheritance of colors from other syntax definitions or the "Language Defaults". There was an increasing amount of reported issues where syntax elements were highlighted with colors from the "Darcula" editor scheme instead of the ones defined by Nord although the values must have been derived from other syntax definitions. This might be caused by the `parent_scheme` attribute which was set to "Darcula". Therefore the attribute has now been removed to mitigate such behavior. Thanks to Tom1206 [3] for the idea of inspecting the attribute. See GH-115 for more details. [1]: https://github.com/JetBrains/intellij-community/search?p=2&q=parent_scheme&unscoped_q=parent_scheme [2]: https://github.com/JetBrains/intellij-community/blob/4491058316bab4162d2ee0a926ac65553b56e6a5/platform/editor-ui-ex/src/com/intellij/openapi/editor/colors/impl/AbstractColorsScheme.java#L311-L313 [3]: https://github.com/Tom1206 Related to GH-115, GH-116
svengreb
pushed a commit
that referenced
this pull request
Feb 14, 2020
This commit implements a change for the meta-issue GH-120 that collects and aggregates all information regarding the problems related to "randomly breaking syntax highlighting". There is an continuously increasing amount of issues related this bug were the root cause is still a mystery. The following timeline shows the problem based on reported issues in this repository. >>> 2019-07-31 - First breakages of Go & JavaScript syntax since IDE versions 2019.2.x The first cases are documented in GH-69 & GH-77 where the syntax highlighting of some Go & JavaScript elements were wrong after updating to IntelliJ version 2019.2.0, the update that introduced support for 20+ languages [1] out-of-the-box by integrating TextMate [2] schemes. It resulted in a change for some Go & JavaScript editor color scheme keys that previously inherited the best matching global keys, but used the attributes defined by the parent theme "Darcula" after the update instead. Therefore Nord's highlighting for Go & JavaScript broke and required to explicitly define the values for the some attributes (merged in GH-70 & GH-78) in order to achieve the same highlight like in previous versions: A comparison of the changes between Nord plugin version 0.6.0 and 0.7.0 [3] shows that there were absolutely no changes to the editor color scheme related to the highlighting of Go & JavaScript code. To this time the guess was that the root cause was the integration of "TextMate" themes and the "fixes" have been released in version 0.8.0 [4]. >>> 2019-12-02 - Second breakage of Go syntax since IDE versions 2019.3.x The second case is documented in GH-108 where the syntax highlighting of some Go elements were wrong again after updating to IntelliJ version 2019.3.0. A comparison of the changes between Nord plugin version 0.8.0 and the time the issue was created (2019-12-02) [5] shows again that there were no changes to the editor color scheme related to the highlighting of Go code. An interesting observation was that the wrong highlighting could be fixed by disabling and enabling the Nord plugin again without restarting the IDE (deny/postpone to later when the question dialog shows up). Again, the "fixes" were then released in a the new plugin version version 0.9.0 [6]. >>> 2020-01-28 - Another breakage of JavaScript & TypeScript syntax in IDE versions 2019.3.x On 2020-01-28 a new issue has been created that describes the breakage of the syntax highlighting for JavaScript as well as TypeScript (which inherits values from the JavaScript editor scheme keys) in GH-115. This is really strange since the affected elements were fixed in GH-78 [7] to mitigate the first breakage! To fix the problem again, the color definitions were then defined explicitly in GH-116 [8] instead of relying on the non-working inheritance of other theme keys. The comparison of the changes between Nord plugin version 0.9.0 and the time the issue was created (2020-01-28) [9] again showing that there were no changes to the highlighting of JavaScript or TypeScript syntax elements in the editor color scheme. It was also possible again to temporarily work around the problem by re-enabling or even re-installing the plugin. This definitely shows that the root cause must be somewhere in the way the IDE loads themes and how editor color scheme keys are inherited from other keys. Again, the "fixes" were then released in a the new plugin version 0.10.0 [10] on 2020-02-11. >>> 2020-02-11 - Now PHP and general "markup" languages are also broken... The latest case occurred only several hours after [Nord plugin version 0.10.0 [10] was deployed and made public through the "JetBrains Plugin Marketplace". This time the highlighting of strings and comments in PHP, Markdown font styles (bold & italic) as well as other elements of "markup" languages are broken. Again, a comparison of the changes between Nord plugin version 0.9.0 and 0.10.0 [11] shows that there no changes to the highlighting for editor color scheme keys for PHP, Markdown or any "markup" languages or "Language Default" styles. During the testing of Nord plugin version 0.10.0, that was released to fix the problems of the broken JavaScript & TypeScript highlighting, there were no problems regarding "markup" styles and all elements were working fine in Markdown files. Right after deploying the plugin to the "JetBrains Plugin Marketplace", the highlighting suddenly broke "out of nowhere" after updating the plugin for my IntelliJ. >> Conclusion These random breakages "drive me nuts" and it's frustrating as a theme author to no being able to track down the root cause. Since the problem occurs randomly, but can also be temporarily mitigated through one or more plugin re-activation or re-installations, the problem origin must be a bug in the IDE itself. >> Mitigation Steps This commit implements a workaround to prevent more styles from breaking. It replaces all editor color scheme keys that inherit values from other keys with the explicit style definitions instead. This causes the code of the editor scheme to increase drastically due to duplicate and repeated styles, but it currently the only way to work around this non-working style inheritance in the IDE theme API. [1]: https://www.jetbrains.com/idea/whatsnew/#v2019-2-editor [2]: https://macromates.com [3]: https://github.com/arcticicestudio/nord-jetbrains/compare/master@%7B2019-05-23%7D...master@%7B2019-07-16%7D [4]: https://github.com/arcticicestudio/nord-jetbrains/releases/tag/v0.8.0 [5]: https://github.com/arcticicestudio/nord-jetbrains/compare/v0.8.0...develop@%7B2019-12-02%7D [6]: https://github.com/arcticicestudio/nord-jetbrains/releases/tag/v0.9.0 [7]: https://github.com/arcticicestudio/nord-jetbrains/pull/78/files#diff-1146aace8d65c51b72c60139418ad4d0R1016-R1018 [8]: https://github.com/arcticicestudio/nord-jetbrains/pull/116/files#diff-1146aace8d65c51b72c60139418ad4d0R1118-R1133 [9]: https://github.com/arcticicestudio/nord-jetbrains/compare/v0.9.0...develop@%7B2020-01-28%7D [10]: https://github.com/arcticicestudio/nord-jetbrains/releases/tag/v0.10.0 [11]: v0.9.0...v0.10.0 Related to GH-69, GH-70, GH-77, GH-78, GH-108, GH-109, GH-115, GH-117, GH-119 GH-120
arcticicestudio
added a commit
that referenced
this pull request
Feb 15, 2020
This commit implements a change for the meta-issue GH-120 that collects and aggregates all information regarding the problems related to "randomly breaking syntax highlighting". There is an continuously increasing amount of issues related this bug were the root cause is still a mystery. The following timeline shows the problem based on reported issues in this repository. >>> 2019-07-31 - First breakages of Go & JavaScript syntax since IDE versions 2019.2.x The first cases are documented in GH-69 & GH-77 where the syntax highlighting of some Go & JavaScript elements were wrong after updating to IntelliJ version 2019.2.0, the update that introduced support for 20+ languages [1] out-of-the-box by integrating TextMate [2] schemes. It resulted in a change for some Go & JavaScript editor color scheme keys that previously inherited the best matching global keys, but used the attributes defined by the parent theme "Darcula" after the update instead. Therefore Nord's highlighting for Go & JavaScript broke and required to explicitly define the values for the some attributes (merged in GH-70 & GH-78) in order to achieve the same highlight like in previous versions: A comparison of the changes between Nord plugin version 0.6.0 and 0.7.0 [3] shows that there were absolutely no changes to the editor color scheme related to the highlighting of Go & JavaScript code. To this time the guess was that the root cause was the integration of "TextMate" themes and the "fixes" have been released in version 0.8.0 [4]. >>> 2019-12-02 - Second breakage of Go syntax since IDE versions 2019.3.x The second case is documented in GH-108 where the syntax highlighting of some Go elements were wrong again after updating to IntelliJ version 2019.3.0. A comparison of the changes between Nord plugin version 0.8.0 and the time the issue was created (2019-12-02) [5] shows again that there were no changes to the editor color scheme related to the highlighting of Go code. An interesting observation was that the wrong highlighting could be fixed by disabling and enabling the Nord plugin again without restarting the IDE (deny/postpone to later when the question dialog shows up). Again, the "fixes" were then released in a the new plugin version version 0.9.0 [6]. >>> 2020-01-28 - Another breakage of JavaScript & TypeScript syntax in IDE versions 2019.3.x On 2020-01-28 a new issue has been created that describes the breakage of the syntax highlighting for JavaScript as well as TypeScript (which inherits values from the JavaScript editor scheme keys) in GH-115. This is really strange since the affected elements were fixed in GH-78 [7] to mitigate the first breakage! To fix the problem again, the color definitions were then defined explicitly in GH-116 [8] instead of relying on the non-working inheritance of other theme keys. The comparison of the changes between Nord plugin version 0.9.0 and the time the issue was created (2020-01-28) [9] again showing that there were no changes to the highlighting of JavaScript or TypeScript syntax elements in the editor color scheme. It was also possible again to temporarily work around the problem by re-enabling or even re-installing the plugin. This definitely shows that the root cause must be somewhere in the way the IDE loads themes and how editor color scheme keys are inherited from other keys. Again, the "fixes" were then released in a the new plugin version 0.10.0 [10] on 2020-02-11. >>> 2020-02-11 - Now PHP and general "markup" languages are also broken... The latest case occurred only several hours after [Nord plugin version 0.10.0 [10] was deployed and made public through the "JetBrains Plugin Marketplace". This time the highlighting of strings and comments in PHP, Markdown font styles (bold & italic) as well as other elements of "markup" languages are broken. Again, a comparison of the changes between Nord plugin version 0.9.0 and 0.10.0 [11] shows that there no changes to the highlighting for editor color scheme keys for PHP, Markdown or any "markup" languages or "Language Default" styles. During the testing of Nord plugin version 0.10.0, that was released to fix the problems of the broken JavaScript & TypeScript highlighting, there were no problems regarding "markup" styles and all elements were working fine in Markdown files. Right after deploying the plugin to the "JetBrains Plugin Marketplace", the highlighting suddenly broke "out of nowhere" after updating the plugin for my IntelliJ. >> Conclusion These random breakages "drive me nuts" and it's frustrating as a theme author to no being able to track down the root cause. Since the problem occurs randomly, but can also be temporarily mitigated through one or more plugin re-activation or re-installations, the problem origin must be a bug in the IDE itself. >> Mitigation Steps This commit implements a workaround to prevent more styles from breaking. It replaces all editor color scheme keys that inherit values from other keys with the explicit style definitions instead. This causes the code of the editor scheme to increase drastically due to duplicate and repeated styles, but it currently the only way to work around this non-working style inheritance in the IDE theme API. [1]: https://www.jetbrains.com/idea/whatsnew/#v2019-2-editor [2]: https://macromates.com [3]: https://github.com/arcticicestudio/nord-jetbrains/compare/master@%7B2019-05-23%7D...master@%7B2019-07-16%7D [4]: https://github.com/arcticicestudio/nord-jetbrains/releases/tag/v0.8.0 [5]: https://github.com/arcticicestudio/nord-jetbrains/compare/v0.8.0...develop@%7B2019-12-02%7D [6]: https://github.com/arcticicestudio/nord-jetbrains/releases/tag/v0.9.0 [7]: https://github.com/arcticicestudio/nord-jetbrains/pull/78/files#diff-1146aace8d65c51b72c60139418ad4d0R1016-R1018 [8]: https://github.com/arcticicestudio/nord-jetbrains/pull/116/files#diff-1146aace8d65c51b72c60139418ad4d0R1118-R1133 [9]: https://github.com/arcticicestudio/nord-jetbrains/compare/v0.9.0...develop@%7B2020-01-28%7D [10]: https://github.com/arcticicestudio/nord-jetbrains/releases/tag/v0.10.0 [11]: v0.9.0...v0.10.0 Related to GH-69, GH-70, GH-77, GH-78, GH-108, GH-109, GH-115, GH-117, GH-119 GH-120
arcticicestudio
added a commit
that referenced
this pull request
Feb 15, 2020
This commit implements a change for the meta-issue GH-120 that collects and aggregates all information regarding the problems related to "randomly breaking syntax highlighting". There is an continuously increasing amount of issues related this bug were the root cause is still a mystery. The following timeline shows the problem based on reported issues in this repository. >>> 2019-07-31 - First breakages of Go & JavaScript syntax since IDE versions 2019.2.x The first cases are documented in GH-69 & GH-77 where the syntax highlighting of some Go & JavaScript elements were wrong after updating to IntelliJ version 2019.2.0, the update that introduced support for 20+ languages [1] out-of-the-box by integrating TextMate [2] schemes. It resulted in a change for some Go & JavaScript editor color scheme keys that previously inherited the best matching global keys, but used the attributes defined by the parent theme "Darcula" after the update instead. Therefore Nord's highlighting for Go & JavaScript broke and required to explicitly define the values for the some attributes (merged in GH-70 & GH-78) in order to achieve the same highlight like in previous versions: A comparison of the changes between Nord plugin version 0.6.0 and 0.7.0 [3] shows that there were absolutely no changes to the editor color scheme related to the highlighting of Go & JavaScript code. To this time the guess was that the root cause was the integration of "TextMate" themes and the "fixes" have been released in version 0.8.0 [4]. >>> 2019-12-02 - Second breakage of Go syntax since IDE versions 2019.3.x The second case is documented in GH-108 where the syntax highlighting of some Go elements were wrong again after updating to IntelliJ version 2019.3.0. A comparison of the changes between Nord plugin version 0.8.0 and the time the issue was created (2019-12-02) [5] shows again that there were no changes to the editor color scheme related to the highlighting of Go code. An interesting observation was that the wrong highlighting could be fixed by disabling and enabling the Nord plugin again without restarting the IDE (deny/postpone to later when the question dialog shows up). Again, the "fixes" were then released in a the new plugin version version 0.9.0 [6]. >>> 2020-01-28 - Another breakage of JavaScript & TypeScript syntax in IDE versions 2019.3.x On 2020-01-28 a new issue has been created that describes the breakage of the syntax highlighting for JavaScript as well as TypeScript (which inherits values from the JavaScript editor scheme keys) in GH-115. This is really strange since the affected elements were fixed in GH-78 [7] to mitigate the first breakage! To fix the problem again, the color definitions were then defined explicitly in GH-116 [8] instead of relying on the non-working inheritance of other theme keys. The comparison of the changes between Nord plugin version 0.9.0 and the time the issue was created (2020-01-28) [9] again showing that there were no changes to the highlighting of JavaScript or TypeScript syntax elements in the editor color scheme. It was also possible again to temporarily work around the problem by re-enabling or even re-installing the plugin. This definitely shows that the root cause must be somewhere in the way the IDE loads themes and how editor color scheme keys are inherited from other keys. Again, the "fixes" were then released in a the new plugin version 0.10.0 [10] on 2020-02-11. >>> 2020-02-11 - Now PHP and general "markup" languages are also broken... The latest case occurred only several hours after [Nord plugin version 0.10.0 [10] was deployed and made public through the "JetBrains Plugin Marketplace". This time the highlighting of strings and comments in PHP, Markdown font styles (bold & italic) as well as other elements of "markup" languages are broken. Again, a comparison of the changes between Nord plugin version 0.9.0 and 0.10.0 [11] shows that there no changes to the highlighting for editor color scheme keys for PHP, Markdown or any "markup" languages or "Language Default" styles. During the testing of Nord plugin version 0.10.0, that was released to fix the problems of the broken JavaScript & TypeScript highlighting, there were no problems regarding "markup" styles and all elements were working fine in Markdown files. Right after deploying the plugin to the "JetBrains Plugin Marketplace", the highlighting suddenly broke "out of nowhere" after updating the plugin for my IntelliJ. >> Conclusion These random breakages "drive me nuts" and it's frustrating as a theme author to no being able to track down the root cause. Since the problem occurs randomly, but can also be temporarily mitigated through one or more plugin re-activation or re-installations, the problem origin must be a bug in the IDE itself. >> Mitigation Steps This commit implements a workaround to prevent more styles from breaking. It replaces all editor color scheme keys that inherit values from other keys with the explicit style definitions instead. This causes the code of the editor scheme to increase drastically due to duplicate and repeated styles, but it currently the only way to work around this non-working style inheritance in the IDE theme API. [1]: https://www.jetbrains.com/idea/whatsnew/#v2019-2-editor [2]: https://macromates.com [3]: https://github.com/arcticicestudio/nord-jetbrains/compare/master@%7B2019-05-23%7D...master@%7B2019-07-16%7D [4]: https://github.com/arcticicestudio/nord-jetbrains/releases/tag/v0.8.0 [5]: https://github.com/arcticicestudio/nord-jetbrains/compare/v0.8.0...develop@%7B2019-12-02%7D [6]: https://github.com/arcticicestudio/nord-jetbrains/releases/tag/v0.9.0 [7]: https://github.com/arcticicestudio/nord-jetbrains/pull/78/files#diff-1146aace8d65c51b72c60139418ad4d0R1016-R1018 [8]: https://github.com/arcticicestudio/nord-jetbrains/pull/116/files#diff-1146aace8d65c51b72c60139418ad4d0R1118-R1133 [9]: https://github.com/arcticicestudio/nord-jetbrains/compare/v0.9.0...develop@%7B2020-01-28%7D [10]: https://github.com/arcticicestudio/nord-jetbrains/releases/tag/v0.10.0 [11]: v0.9.0...v0.10.0 Related to GH-69, GH-70, GH-77, GH-78, GH-108, GH-109, GH-115, GH-117, GH-119 GH-120
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #115
As of IDE versions 2019.3.x, some TypeScript and JavaScript syntax elements were not highlighted correctly. The following elements inherited the colors from the Darcula parent scheme instead of the language defaults defined by Nord:
These elements are now using explicitly defined colors instead to fix the highlighting.
Before
After