OpenAPI: move class


I'm working on this issue (that I created) :

I fount that the class who manage a part of missing options is :


I used


to add missing fallback attribute key, but the problem is they are in two different modules. CodeInsightColors is in "core-api" module, and "DefaultLanguageHighlighterColors" is in the editor-ui-api module, and both modules are not dependants. Solution I fount is to move "DefaultLanguageHighlighterColors" and "HighlighterColors" to "core-api" module, but as it's an API, i'm not sure I can just move them.

What shoud I do exactly in this case ? Note that what I did should solve the issue (I have to check for possible missing items though).

Comment actions Permalink

It's not that simple. In reality CodeInsightColors contains both Java-specific attributes and generic ones for reasons I'd call "historical". It has to be split with Java part moved to javaimpl. There is also Java-specific SyntaxHighlighterColors which lives in "editor-ui-api" module which is wrong too. It has to be merged with Java-specific part of CodeInsightColors and moved to "java-impl". And we can't change it easily since currently all this is a part of API. SyntaxHighlighterColors has been deprecated for quite a while so perhaps moving it to JavaHighlightingColors is safe enough but CodeInsightColors must be deprecated first and links to it made in JavaHighlightingColors.

Comment actions Permalink

Okay, I see.

I checked and SyntaxHighlighterColors was used only in com.intellij.ide.highlighter.JavaHighlightingColors and in com.intellij.usages.ChunkExtractor#isHighlightedAsComment & com.intellij.usages.ChunkExtractor#isHighlightedAsString (at least in the community code). I did the necessary changes and deleted the class as equivalent already exist in com.intellij.openapi.editor.DefaultLanguageHighlighterColors.

I'll do a pull request for that and see what I can do for CodeInsightColors.

Comment actions Permalink

Now I think about it, maybe it's better to keep this class, but deprecated language' related fields (CLASS_NAME, STATIC_FIELD, METHOD_CALL, ...) but keep code analysis' field (WRONG_REFERENCES_ATTRIBUTES, ERRORS_ATTRIBUTES, ...).
In case we deprecate the entire class, which class replace it for code analysis fields?

Currently, in JavaHighlightingColors, all initialized TextAttributeKey has there equivalent in DefaultLanguageHighlighterColors. Is it really necessary to re-declare all of them?
I suppose it's done in case of a key change (ex: public static final TextAttributesKey LINE_COMMENT = DefaultLanguageHighlighterColors.LINE_COMMENT; is changed to public static final TextAttributesKey LINE_COMMENT = DefaultLanguageHighlighterColors.BLOCK_COMMENT; ), to avoid breaking the code. Am I right? If it's not the case, I think it could be a good idea to deprecate them and replace them with DefaultLanguageHighlighterColors' keys.


Please sign in to leave a comment.