Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with PHP Syntax, string concatenation and statements #119

Closed
kedodrill opened this issue Feb 11, 2020 · 8 comments · Fixed by #116, #109, #121 or #137
Closed

Issues with PHP Syntax, string concatenation and statements #119

kedodrill opened this issue Feb 11, 2020 · 8 comments · Fixed by #116, #109, #121 or #137

Comments

@kedodrill
Copy link

kedodrill commented Feb 11, 2020

Hi there,

First of all, thank you so much for creating this theme! I love it and I always apply it to any editor I use.

The most recent update that was published to the Jetbrains plugin marketplace a few hours ago seemed to have broken some PHP syntax for me, mostly (I think) string concatenation. Screenshots below.

Everything here seems to be fine.

testclass

This seems to be the main issue. See middle of screenshot for weird syntax highlighting.
I am not sure if accessors for objects was like that before (all white), but I do feel like maybe there was some color there?

testnord

Again, things here seem fine, accessing values from an array works great, so I think the concat might be the issue here?

script

EDIT Additionally, the highlighting is completely greyed out when the array is inside statement blocks, screenshot below shows a foreach and a for loop.

arraysyntax

If you need anymore information please let me know. Thanks!

@kedodrill kedodrill changed the title Issues with PHP Syntax, string concatenation Issues with PHP Syntax, string concatenation and statements Feb 11, 2020
@arcticicestudio
Copy link
Contributor

arcticicestudio commented Feb 11, 2020

Hi @kedodrill 👋, thanks for your contribution 👍
Nice to see you like Nord 😄

You're not alone with this problem. After deploying the plugin to the JetBrains Plugin Marketplace and updating most of my markup related syntax elements, like links/URLs and bold text as well as some braces in code blocks are highlighted with wrong colors like on your screenshots.

This is a really strange and absolutely annoying bug of the IDE's theme engine. These elements were highlighted correctly while testing the changes made in version 0.10.0, but none of these changes are related in any way to markup elements. The same problem now occurred multiple times after IDE minor and patch version updates while no single line of code in the theme plugin itself has been changed. This drives me nuts 😒

I'll create a meta-issue to collect the information of all the already resolved tickets in this repository regarding this defect syntax highlighting. For many users the plugin "broke" without touching the plugins code.
Afterwards I will open a issue in the JetBrains bug tracker so this can finally be fixed in the IDE itself. Maybe a quick workaround is to replace all the highlighting definitions in the Nord plugin where colors are inherited from other values and explicitly define them instead. This worked fine in the past and is currently the only solution to get around these problems.


Related to #115, #100, #108, #109

@arcticicestudio
Copy link
Contributor

Sometimes a quick workaround is also to disable and enable the plugin again. After a restart there's a 95% chance (sigh) that inherited color definitions are applied correctly 😐

@kedodrill
Copy link
Author

@arcticicestudio Hi Sven, thanks for the quick response. I did go through and read #115, but I figured I'd go ahead and make a new issue because I thought that this was a new issue that was caused by that update. Are you saying it's on the Jetbrains side?

Sounds like a plan though, thanks for the information. Is that workaround something that I can do locally? Or are you talking about a quick bandaid solution for now?

I did disable and enable it first, then I uninstalled it, went through my files and deleted the package and reinstalled it. No luck :(

@arcticicestudio
Copy link
Contributor

Wrote down the history and current situation of this problem in #120.

@kedodrill
Copy link
Author

@arcticicestudio Awesome! Feel free to close this issue whenever you need to. If you need any other information from me let me know. Thank you :)

svengreb pushed a commit that referenced this issue 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 issue 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 issue Feb 15, 2020
In GH-117, the `parent_scheme` attribute has been removed since it was
suspected that it caused "random highlighting breakages" that are
documented in detail in GH-120.

Anyway, contrary to the presumption that the attribute is not required,
it caused syntax elements of many different languages to ignore some
colors defined by the Nord plugin, like e.g. "markup" elements in
(documentation) comments, strings in PHP (GH-119), data flow control
characters like braces in TypeScript/JavaScript and even UI elements
like tabs. See feedback comments of @Tom1206 [1] and @yuru7 [2] in
GH-120 for more examples.

The color `#808080` was used for all these elements instead which is
"hardcoded" in different places in the IDE core platform code [3].
It was not possible to fix these elements using the available editor
scheme keys.

By simply adding back the attribute with the value `Darcula` all these
elements will "magically" use the colors defined by Nord again instead
of `#808080`. It is a strange behavior that this attribute is required
for almost no reason, but it has been added back again to fix the
massive style problems occurred as of Nord plugin version 0.10.0 [4] in
combination with the latest IDE versions 2019.3.3 [5] (that was release
the same day like the plugin update...)

[1]: https://github.com/Tom1206
[2]: https://github.com/yuru7
[3]: https://github.com/JetBrains/intellij-community/search?q=808080&unscoped_q=808080
[4]: https://github.com/arcticicestudio/nord-jetbrains/releases/tag/v0.10.0
[5]: https://blog.jetbrains.com/idea/2020/02/intellij-idea-2019-3-3-is-out

GH-129, GH-119
@arcticicestudio
Copy link
Contributor

Thanks for your feedback 👍
Submitted #137 to fix this and many other highlighting problems, details are documented in #129.

arcticicestudio added a commit that referenced this issue Feb 15, 2020
In GH-117, the `parent_scheme` attribute has been removed since it was
suspected that it caused "random highlighting breakages" that are
documented in detail in GH-120.

Anyway, contrary to the presumption that the attribute is not required,
it caused syntax elements of many different languages to ignore some
colors defined by the Nord plugin, like e.g. "markup" elements in
(documentation) comments, strings in PHP (GH-119), data flow control
characters like braces in TypeScript/JavaScript and even UI elements
like tabs. See feedback comments of @Tom1206 [1] and @yuru7 [2] in
GH-120 for more examples.

The color `#808080` was used for all these elements instead which is
"hardcoded" in different places in the IDE core platform code [3].
It was not possible to fix these elements using the available editor
scheme keys.

By simply adding back the attribute with the value `Darcula` all these
elements will "magically" use the colors defined by Nord again instead
of `#808080`. It is a strange behavior that this attribute is required
for almost no reason, but it has been added back again to fix the
massive style problems occurred as of Nord plugin version 0.10.0 [4] in
combination with the latest IDE versions 2019.3.3 [5] (that was release
the same day like the plugin update...)

[1]: https://github.com/Tom1206
[2]: https://github.com/yuru7
[3]: https://github.com/JetBrains/intellij-community/search?q=808080&unscoped_q=808080
[4]: https://github.com/arcticicestudio/nord-jetbrains/releases/tag/v0.10.0
[5]: https://blog.jetbrains.com/idea/2020/02/intellij-idea-2019-3-3-is-out

Fixes GH-129, GH-119
arcticicestudio added a commit that referenced this issue 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 issue Feb 15, 2020
In GH-117, the `parent_scheme` attribute has been removed since it was
suspected that it caused "random highlighting breakages" that are
documented in detail in GH-120.

Anyway, contrary to the presumption that the attribute is not required,
it caused syntax elements of many different languages to ignore some
colors defined by the Nord plugin, like e.g. "markup" elements in
(documentation) comments, strings in PHP (GH-119), data flow control
characters like braces in TypeScript/JavaScript and even UI elements
like tabs. See feedback comments of @Tom1206 [1] and @yuru7 [2] in
GH-120 for more examples.

The color `#808080` was used for all these elements instead which is
"hardcoded" in different places in the IDE core platform code [3].
It was not possible to fix these elements using the available editor
scheme keys.

By simply adding back the attribute with the value `Darcula` all these
elements will "magically" use the colors defined by Nord again instead
of `#808080`. It is a strange behavior that this attribute is required
for almost no reason, but it has been added back again to fix the
massive style problems occurred as of Nord plugin version 0.10.0 [4] in
combination with the latest IDE versions 2019.3.3 [5] (that was release
the same day like the plugin update...)

[1]: https://github.com/Tom1206
[2]: https://github.com/yuru7
[3]: https://github.com/JetBrains/intellij-community/search?q=808080&unscoped_q=808080
[4]: https://github.com/arcticicestudio/nord-jetbrains/releases/tag/v0.10.0
[5]: https://blog.jetbrains.com/idea/2020/02/intellij-idea-2019-3-3-is-out

Fixes GH-129, GH-119
@kedodrill
Copy link
Author

Don't wanna clutter up your PR's or anything, so just wanted to confirm that everything seems to be working fine for me with the latest update (0.11.2)! 🎉

@arcticicestudio
Copy link
Contributor

Don't worry, that's the main use case of the comment box in issues and PRs. Feedback is always welcome 😄
Great to see it works for you now!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment