Intellij-elixir: IntelliJ 2016.1 deprecates some color constants

[vladshcherbin]

Code highlighting is broken, colors in settings (for example for type) are deprecated.

IntelliJ IDEA (Minerva) IU-145.184.1
Build #IU-145.184, built on March 1, 2016
Elixir Plugin 2.2.0

[vladshcherbin]

Same with the previous version, probably settings were changed in EAP version.

[KronicDeth]

Is there a deprecation warning in the UI? Can you post a screenshot? I've tried to target the oldest version of IDEA that I can for maximum compatibility, so I need to figure out what constants to use instead and how early they were introduced, so I can update the compatibility information.

[vladshcherbin]

Yes, there is a __deprecated__ word, 4 rules are with it

[thirdshift]

First, thanks for making the plugin.

IntelliJ IU-IDEA 143.2287
Elixir Plugin 2.2.0

I'm not seeing the deprecations that Vlad is seeing, but it looks like some color settings are being ignored. This screen shot is using an unmodified Darcula theme.

[KronicDeth]

@thirdshift, it works for you because you're using IDEA 143., @VladShcherbin is reporting that in 145., which is the EAP, or Early Access Preview, of the upcoming release, the colors constants I'm using are deprecated, so it's like a heads up that the plugin will break when the next version of IntelliJ is released.

Your screenshot doesn't have any Type elements in it, so I wouldn't expect you to see the color. Open up a file with @type, @spec, or @callback in it. For example, here's what lib/elixir/access.ex should look like

[thirdshift]

From my original screenshot I was thinking things like "def" and "import" would be colored in some way. So I came looking at the issues and likely mistakenly added to this one. I can see in your screenshot that "def" and "defmacrop" are not colored either. So I am guessing that must be functioning as designed.

[KronicDeth]

@thirdshift def and defmacrop use the Kernel Macros color, which inherit from the Identifiers -> Function call of Language Defaults. In Darcula Identifiers -> Function call has no colors or style associated with it. I didn't use the Keyword color from Language Defaults because developers shouldn't start thinking of the Kernel macros like def and defmacro as Elixir keywords. Elixir has real keywords like else, after, do and end, which use the Keyword color.

Looking at the settings I have just realized that there is no override for the Keyword color in the Elixir settings, it can only inherit from the Language default. I'll open a bug for that.

[thirdshift]

Thanks for taking the time to explain that to me.

[sprobst]

@KronicDeth Thank you, after your explanation I could alter the color settings in a way that Kernel Macros are highlighted how I like it.
Though I think it's confusing, because the Atom Editor for example highlights Kernel Macros like Keywords by default. I therefore always thought your plugin was broken in some way.

[KronicDeth]

I finally installed 2016.1 for my production copy and it has the the deprecated for Type, so 2016.1 includes the Minerva changes. I'll have to update my community edition, so that the bug shows up in the debug builds. Then, I'll need to figure out if there's a constant that will work in 14, 15, and 2016, or if I'll need to drop 14 or 15 support to support 2016. If I don't use one of the predefined constants, then users would have to set the setting since it won't be in the default themes.

[vladshcherbin]

@KronicDeth great, thank you! Any ETA on when will it be available to install in IDEA?

[KronicDeth]

I've been testing out a release candidate (i.e. I just did Build Artifacts and installed the zip locally, which you're welcome to do) today and hit some bugs (not related to the color constants) I need to check before release. Once that's sorted out I need to update the README to include all the changes (I don't add things to the README as they are merged to master anymore as people kept opening issues that features in the master README weren't in the software they were using because they assumed everything in the master README is released and didn't check their release's tag's README), so probably a day or two at least depending on how complicated the bugs are.

[vladshcherbin]

@KronicDeth sure, take all the time you need to fix the bugs. Thank you for your work!