Color parsing and display should be based on filetype and directory

bfricka commented 11 months ago

Describe the bug In TypeScript and JavaScript files, as well as several other file types, the expected color format would be #RRGGBBAA (or even #RGBA for shorthand notation, but this is more rare). This package seems to assume Android color format, which is #AARRGGBB. The result of this is that colors opaque colors highlight well in all contexts, and alpha colors in the Android dev context, but colors with alpha don't really make sense in other contexts.

This obviously isn't ever going to be perfect. Kotlin and Java files (and related XML) can be defined with colors that are designed to interface with w/ other environments like web, Node, or other languages. However, it should be reasonable to infer the default context based on filetype and location.

I would suggest the default should be #RRGGBBAA. This way it's Android's way and everything else. You could then parse as #AARRGGBB if you're in a non TS/JS file that's within android/src/main.

You could also do the inverse, and parse #RRGGBBAA only if you're in a JS/TS file, but this is less versatile because anything defined in JSON, XML, YAML in a web / node or other project wouldn't parse correctly.

To Reproduce

Create a JS/TS file
const RED_50 = '#FF000080'

Should look like full red at 50% opacity. Instead looks like dark blue at full opacity.

Expected Behavior Android context colors parse with alpha parse differently based on context. JS/TS and other files that define HEXA should parse and display correctly.

Environment

IntelliJ IDEA 2023.1.3 (Ultimate Edition)
Build #IU-231.9161.38, built on June 19, 2023
Runtime version: 17.0.7+10-b829.16 x86_64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
macOS 13.5
GC: G1 Young Generation, G1 Old Generation
Memory: 2048M
Cores: 16
Metal Rendering is ON
Registry:
    editor.injected.highlighting.enabled=false
    debugger.new.tool.window.layout=true
    editor.distraction.free.mode=true
    ide.tooltip.initialDelay=504
    ide.experimental.ui=true
    ide.balloon.shadow.size=0
    ide.images.show.chessboard=true

Non-Bundled Plugins:
    monokai-pro (1.10)
    String Manipulation (9.9.0)
    com.mallowigi.colorHighlighter (15.0.0)
    izhangzhihao.rainbow.brackets (2023.2.11)

Kotlin: 231-1.8.21-IJ9161.38

Screenshots 50% red as defined using the "Android" style android-red

50% red defined using HEXA ts-red

mallowigi commented 11 months ago

You know that you can switch the format in the settings, right? However I like the idea of checking the context. I don't know yet if this is possible in the current implementation, but this is a clue I'll try to investigate

mallowigi commented 11 months ago

Going back to this discussion. After consideration, I will leave the setting decide whether to use argb or rgba, but will change the default to rgba.

The reason is that it's not necessarily the case. Unlike Color(r,g,b,a) or NSColor or rgba(r,g,b,a) that are of course straightforward, hex colors are agnostic. True, CSS uses #rgba (or #rrggbbaa) and android uses #argb, but JS, TS, Python, Markdown or others are depending on the implementation.

What if you use a library that parses argb instead of rgba? What if my HTML elements use a data attribute that expects a argb color string? etc etc.

AtomMaterialUI / color-highlighter

Color parsing and display should be based on filetype and directory #116