Yellow function names in WebStorm 2019.3xx #115
Comments
|
Hi @mariojackson 👋 This is a known problem and it might be that you're using a customized copy of Nord. When setting a color or UI theme that is provided by a plugin and editing any of the editor's code styles, the IDE will automatically create a copy of the theme with your modifications. If there's a file named Anyway, it's interesting to see that it work fine in GoLand for JavaSript/TypeScript code even though WebStorm is focused on such web-scoped languages 🤔 |
|
Thanks for getting back at me so quickly. I've went to the specified To make sure that I did not miss anything, I went ahead and deleted the whole To double check, I went into the
I have not been exact with |
|
P.S. on macOS the |
|
First of: Thanks a lot for your sponsorship 💙 The I had the idea that your problem might be the same like the one fixed in #77: Some default values of syntax highlighting theme keys are not set correctly (like described in #77) by inheriting the parent theme key so they fall back to the default JetBrains theme (Darcula). My guess is that this is the case for functions of the TypeScript syntax theme keys. |
|
You are welcome! Thanks for creating this theme and porting it to different applications :). It could be that it is your stated problem. I hope that you do manage to fix it without investing too much time. Please let me know if I can help or if you need any further information. |
Is this a requirement to have Nord use |
|
@Tom1206 That's a good question 👍 The editor scheme was initially created a long time ago way before the new UI theme API has been introduced. Maybe this causes the colors from using the defined |
|
I've tested a lot scenarios and came up with some interesting results. Unfortunately there is only a spare amount of documentation about the syntax and XML schema of editor color schemes, so this required some time to get into the IntelliJ Community Edition source code that is the origin code base for all JetBrain IDEs. Colors only applied correct after restart. 
Anyway, @Tom1206's idea might be a good start to mitigate the problem since it looks like the <scheme name="Nord copy" version="142">I removed the Some colors are still inherited from Darcula even after removing the Quick Doc of React component 
Quick Doc of constant 
Quick Doc of function 
Quick Doc of React props 
Quick Doc of TypeScript type 
As you can see, there are still the wrong colors of the Darcula theme. @mariojackson Could you please manually install the following plugin to see if it works for you? It's the test with the removed nord-jetbrains-no_parent_scheme.zip While searching for some documentations about the XML schema of editor color scheme, I also stumbled across a blog post from 2017 that includes information about a 
I'll add this tag to Nord to see if this (positively) affects and improves the loading of the correct colors for the syntax elements. If all of that doesn't help, I'll go with the way that worked for the same problems with the Go programming language: Adding explicit support for the theme keys of TypeScript and JavaScript syntax elements instead of letting them inherit the colors from base elements of the theme. |
|
This (IDE) bug really bothers me a lot since it can appear for many other languages whose syntax highlighting definitions are changed in upcoming IDE updates and versions. The inherited values are a great way to prevent theme breakage, but when they don't work the way they should it's a feature of the IDE that is almost useless 😞 Anyway, I'll definitively want to fix this since I'm currently also trying to move my whole development workflow for TypeScript/javaScript/React based applications from VS Code to IntelliJ (which has all the features of WebStorm since all other IDEs are only "lightweight" variants of IntelliJ 😄 ). I use IntelliJ for all of my projects, mainly Go and some Java/Spring for my job, but sticked with VS Code for TypeScript/javaScript/React since it works fine out-of-the-box with due to the fact that it itself is written in TypeScript. The only reason not to use IntelliJ was that some years ago the support for TypeScript with React and all of the ecosystem (Babel, Prettier, Yarn etc.) was not really existent, but today it works like a charm thanks to unified systems like the “language server“ specification and protocols. Even compiler/transpiler/bundler feature like import aliases are not a problem anymore 💯 |
|
First of all thank you for all your already invested time into fixing this bug 😄 I've also started with IntelliJ in the past which was my only IDE. When working with big projects, my IDE was slowing down a little because it indexed all the files and the RAM was getting a little out of hand. Therefore I decided to use the 'stripped down' versions when possible to have a more smooth experience, since less total plugins are installed and thus less plugins taking resources for analyzing the code (other plugins were analyzing code even though it wasn't needed but you can disable this). But it's not worth the extra bucks I'd say. I also like VSCode for smaller projects but the autocompletion, intellisens and the nice hints make the JetBrains products my preferable ones. I just wanted to ask you about the link to the plugin file to download, but just saw that you have now already provided it. Thank you! I also like it very much that you always take your time when answering, since your answers are always very thoughtful and it also shows that you care. This is one of the reasons why I decided to sponsor the first time ever on Github. Also, your website does look very good :). I just installed the provided plugin locally from disk and it works even after an IDE restart 🎉 |
|
Hi, Anyway, I also tried installing |
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
arcticicestudio
added
target-intellij-idea
target-webstorm
type-bug
and removed
status-pending
type-support
labels
|
@mariojackson Using a "lightweight" JetBrains IDE makes total sense when you're scoped to a specific type of development like e.g. WebStorm for web & frontend work. I guess that the main reason why all these different exist at all, otherwise IntelliJ would be the one-for-all solution 😉 : Also thanks for the kind words, feedback like this makes it fun to work on any open source project! @Tom1206 Nice to see you like Nord that much! You really don't want to use any other IDE aynmore after using one from JetBrains, it's like coding on steroids 😄 And by the way: I haven't fixed it, I've only applied the idea of the |
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 commit 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 were 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. See GH-115 [3] for mroe 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]: #115 GH-115
|
Also submitted #117 in order to remove the |
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
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
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
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
|
The fix has been merged and released in version 0.10.0 🏷 |
|
@arcticicestudio awesome! Thank you for your great work Sven! Also, I'm a "full stack" developer myself and also love using Go 😄 Have a great day! |
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
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
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
Hi,
I'm getting a lot of yellow colors after the installation of the Nord theme in WebStorm 2019.3xx. This happens only after the initial installation and a restart of the IDE. Before the restart, the yellow colors are a light blue one (I guess the correct one). This happens on both Arch Linux and macOS Catalina. However, this does not happen in GoLand for example.
After initial plugin installation and before the restart
After IDE restart
After the first restart, the colors stay like that.
It seems to be related to #77. My Nord plugin version installed is 0.9.0
Thank for creating my favorite theme and please let me know if you need any further information regarding the issue.
The text was updated successfully, but these errors were encountered: