IMHO, I feel like this is more suited to a plugin, once that's become functional, and not something that should be built-in.

So I mostly agree with @cole-h about this being suited for a plugin. On the other hand, I was very surprised to find this in LSP specs today: https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocument_documentColor.

Despite the discussion if this should be a native option I would like to add a few wishes for config options:

• for the virtual display and the gutter/sign column display it would be cool if there where three options: Square, Circle and Unicode with an additional variable that takes the Unicode character as a String.
• if it is possible to control the thickness of an underline it would also be nice to have that as an option as well
• I guess an outline option is not feasibly achievable for a terminal editor, right?

Would it possible to implement this as a tree-sitter? I have no idea if it is possible to have to tree-sitter modules running on a single file..

It should be possible to write a tree-sitter grammar for colors, and then that grammar can be injected into things like toml strings (for editing themes for example) or css values. The only thing that wouldn't work without modification I think would be choosing the colors, so you would have runtime/queries/colors/highlights.scm that would capture colors, but then you'd have to extend the query DSL to be able to highlight using the captured color token instead of consulting the theme for the capture name.

I don't think that would be an unreasonably tough change to make because there's already somewhat similar machinery for injections.scm that allows you to capture the injection language using the query DSL, as in markdown

I gave a try to the LSP based color highlighting: https://github.com/matoous/helix/tree/md/lsp-document-colors but it doesn't play nicely with the current text highlighting as the current implmentation is heavily centered around the highlight queries and doesn't support passing in arbitrary colors. The implementation for now works as an overlay: the highlight is applied only after everything else is rendered. I still have some issues with indexing and the highlights are off but you can already try it for example on css/scss files.

@matoous Thank you for implementing this. I tried to get it to work, but I cannot see any color hints in my test CSS file. How do I activate mentioned overlay?

The PR is severely outdated, so I am not sure if it still works. I tried with scss files as far as I recall and it worker but there were some issues with positioning etc. Do you have appropriate LSP installed?

This might be also a question for @pascalkuthe , as far as I remember from implementing this: TextAnnotations don't support custom color per overlay so we would have to create TextAnnotation per document color which I don't think is the intended use case.

I actually made it work by changing the default in the LspConfig and recompile. I hope this finds its way into some working module. Without the offset, of course

This will be very helpful indeed! I am trying to create a series of new themes for Helix, but have to resort to using other editors to help me preview the colors I entered.

Can be implemented in Helix by implementing the aforementioned LSP method.

The only thing that bloats this a little is that all highlights at the moment use usize which is reference to a color from the theme. For displaying the color we would have to either add some custom logic or make the highlight an enum that could alternatively use any color.