Add possibility to use predefined highlight.js themes

[vladshcherbin]

Since this library is using highlight.js, it would be cool to be able to use its themes out of the box.

[idleberg]

I'm not sure whether this is possible. For example, it's my understanding that the color red would not be the one defined in a highlight.js style-sheet, but from the Terminal's colours. There might still be little benefit in supporting highlight.js, since logic-wise they often differ from each other. However, they wouldn't use the colours you'd expect them to.

[F1LT3R]

@idleberg is correct. Themes would work for some terminals that support all colors, but not all colors will work in all terminals.

Even so, we could make the themes works for those who did have them available.

I'm not sure I can take this on right now, but I can assist if someone wants to work on a PR together.

[idleberg]

Actuall, it should work in terminals that support true color. The Rust app bat does this.

[F1LT3R]

If someone submits a pr with the option for 1) using true color when supported, and 2) mapping highlight js css colors and providing a way to make this extension, I'll review and update the package. It's a good request.

[idleberg]

I've been looking into it and the real question to me is how to treat fallbacks. The easiest would be to fall back to the defaults that are currently defined in darkPalette. At the same time this kind of defies the point of supporting styles when the result isn't complete or faithful.

Here are some questions that came up:

1. Are the color-names in darkPalette modelled after the Highlight.js class-names?

2. What about colors that aren't part of Highlight.js, e.g. line-numbers? Should we only style the actual code?

[F1LT3R]

Good questions.

I originally based this on terminal color names, not really thinking about existing theme's, as there are places in which you just can't control the colors, (like some cloud server you can't update the machine image), it didn't make sense to try and control colors at that level.

You can check for the presence of various color support with some of sindresorhus's modules I believe, so you could switch behavior based on colors available to term, plus a true color flag passed into opts.

I'm not sure if it's possible to query the exact colors a terminal uses, so I don't think you could do a conversation algorithm to get to the closest colors.

You could assume that if you pass in a css Theme, that it will use true colors if the term supports true colors. That might work, and be least confusing.

I would see line numbers, etc as being a separate setting.

[idleberg]

You can check for the presence of various color support with some of sindresorhus's modules I believe, so you could switch behavior based on colors available to term, plus a true color flag passed into opts.

I was thinking about using supports-color:

if (supportsColor.stderr.has16m) {
    // Parse CSS theme
    // Apply colors from CSS using chalk
}

In fact I've just started on a parser for Highlight.js themes, should be easy to integrate.

I'm not sure if it's possible to query the exact colors a terminal uses, so I don't think you could do a conversation algorithm to get to the closest colors.

This is interesting, but I didn't even think that far. Maybe a nice to have for later?

By the way, if this works out and people like it, we could also support Base16 themes. There will probably be less trouble (or none) with fallback options.