Random editor scheme highlight breakage

[arcticicestudio]

This is a meta-issue to collect and aggregate 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.

Related to #69, #70, #77, #78, #108, #109, #115, #117, #119

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 #69 & #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 out-of-the-box by integrating TextMate 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 #70 & #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 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.

2019-12-02 — Second breakage of Go syntax since IDE versions 2019.3.x

The second case is documented in #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)comp-time-v0.8.0-2019-12-02 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 0.9.0.

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 #115. This is really strange since the affected elements were fixed in #78 to mitigate the first breakage!
To fix the problem again, the color definitions were then defined explicitly in #116 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) 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 version 0.10.0 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 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 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.

Next Steps

1. Implement workaround for other possible breakages — To prevent more styles from breaking, I'll replace 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.
2. Submit a bug report to the JetBrains IntelliJ bug tracker — In order to get rid of this annoying bug, I'll submit a detailed bug report to the JetBrains bug tracker for the IntelliJ IDE including the details of this issue.

Feedback Always Welcome!

If you're also affected by this problem, I'll really appreciate every feedback so this can be used to find the root cause and fix this bug permanently 🚀

[Tom1206]

I have also encountered a few scheme bugs since the 0.10 update.
The first one is with all colors (hex, name, variables, ...) on CSS (and SCSS, ...) files. They have a brownish color, as shown in the screenshot :

I can't fix it with the color scheme settings unfortunately (nor with any restart, or reinstall of the plugin) :

I reinstalled 0.9 to try, and the problem doesn't exist there...
I fear that the "unused" attribute parent_scheme wasn't so unused after all, because there is a few other things broken (I will report). It seemed to fix fine a few badly inherited colors, but introduced random brownish elements here and there.

[Tom1206]

The active tab is now the wrong color, somehow...

Easily fixed in the settings :

[Tom1206]

The Diff & Merge folded code is the wrong color on 0.10:

Easily fixed by adding a color to the background:

[yuru7]

I have the same appearance.

The following capture is "pom.xml" of Maven.
Some are normal, some are broken (brown text color).

After reinstalling Nord v0.9, the problem was fixed.

[Tom1206]

There is a problem with function parameters when there is a suggestion in Typescript.

Edit : It seems to append only on Webstorm on my Mac, not on Windows.

[arcticicestudio]

Thanks @Tom1206 and @yuru7 for your feedback 💪

As a first mitigation step towards the "random" color breakage, I've implemented and submitted the change to replace all inherited colors with their explicit definitions in #121. The only small quirk of the change is the increased amount of definitions, but I've checked other builtin and community themes and most of them don't make use of inherited colors (no baseAttributes set). A advantage of this change is that there's now "less magic": Instead of relying on the default color inheritance, every theme key for a syntax is now within the color scheme file making it way easier to find and modify them.

There's also another factor that might be reason for the wrong colors both of you found: The latest IDE versions 2019.3.3 have been released at the same day like the Nord plugin version 0.10.0 🙃
I've quickly checked the changes and it looks like they've also introduced some changes to editor color schemes as well as new keys that affect the UI, e.g. there are new TAB_* editor scheme keys which might explain the behavior @Tom1206 found.

Next steps: fix the problems both of you found and going through the color scheme keys again to add support for new or changed keys. I'll try to forge a new plugin version 0.11.0 over the weekend.

[Tom1206]

There is a few other brownish colours here and there:

edit : this is probably #127

This one is quite common in C#

I just wanna say, thank you @arcticicestudio for all your work these last few days, it's amazing to see how much you care about the quality of Nord, and how much you communicate about it.

[arcticicestudio]

Thanks for all the feedback 💙
The actual fix for all these broken colors was indeed the removed parent_scheme attribute. This is so strange that it is required to add this, otherwise many of the defined colors of a theme are simply ignored. I've written down some more details in #129 and reverted the change in #137.
I'll release and deploy plugin version 0.11.0 to the marketplace this evening which also includes some other new features.

---

Closed by #129, #137