Allow user to add custom highlighting themes

[Bobo1239]

It would be great if users couldn't just add custom highlighting syntaxes (possible since 0.4.2) but also custom highlighting themes without the need to add them to gutenberg itself.

[Keats]

I'm not entirely against that but I would rather have as many themes as possible in Gutenberg. Custom syntaxes make sense because some people are developing their own language but it's not the case really for themes.
I do plan to add all of https://boostlog.io/@junp1234/10-best-sublime-text-themes-of-2018-5b23805a44deba0054046809 for example though

[chris-morgan]

There are a great many themes out there, that came about because people do develop their own themes. I interact with more people that I know have modified text editor themes or written themes from scratch than I know have written syntax highlighters. (I’ve done all three many times over.)

I think this variation may actually be a bigger deal for websites than for text editors: in the text editor the theme exists in relative isolation, but inside Zola syntax highlighting exists inside the rest of the site theme. The likes of Zola attract power users that care about such details. In my own fork of Zola (I’m sure to want other variations of stock functionality), I’m going to need to do this.

I believe that syntax highlighting themes should be part of the regular theme system. I don’t think that’s too radical a notion. If you want something more radical, I believe that including any highlighting themes out of the box is a misfeature—just as no site themes are included out of the box. There are decent repositories of TextMate themes out there already, and it’s easy to drop the .tmTheme.txt file in.

[Keats]

If someone wants to send a PR, code changes can probably almost follow the syntax changes. In the config and rendering subcrates.

If you want something more radical, I believe that including any highlighting themes out of the box is a misfeature—just as no site themes are included out of the box. There are decent repositories of TextMate themes out there already, and it’s easy to drop the .tmTheme.txt file in.

I disagree on that, it would make syntax highlighting unusable without going on some random websites.

[chris-morgan]

Correct, it would make syntax highlighting unusable without work. But Zola already requires you to find or make a theme; that’s why I don’t consider it as outlandish as all that, merely fairly radical.

[Keats]

But Zola already requires you to find or make a theme

It also requires you to write some content :)
Themes are something I consider to be personal. I don't use pre-made themes: the only reason they are supported in Zola is because many people don't feel the same way.
There is an issue #534 to help with the setup but I don't really to build/support n built-in themes for n usecases right now.

[berkus]

Would be great to actually be able to just specify a location with Sublime Text highlighting configuration and have that theme added automagically, much like it's done currently with ST syntaxes.

[drmason13]

Would be great to actually be able to just specify a location with Sublime Text highlighting configuration and have that theme added automagically, much like it's done currently with ST syntaxes.

I'd like to have a go at implementing this. I've looked at how bat does it for inspiration and it seems easy

https://github.com/sharkdp/bat/blob/master/src/assets.rs

Kudos to syntect's author for all the convenience functions!

As a user, with bat, adding a theme is as simple as:
https://github.com/sharkdp/bat#adding-new-themes

[pinpox]

Any updates on this? I'd to modify the syntax colors with sass variables but don't know if that's possible somehow

[Keats]

I'd to modify the syntax colors with sass variables but don't know if that's possible somehow

That wouldn't be possible with that feature still. After #1242 you could create some class in your scss files and it should work.

[drmason13]

Sorry I've not even made a start on this, but it is still something I want to find time for!

[drmason13]

I started this in earnest today. It is a little tricky because storing the ThemeSet is difficult.
It doesn't implement Clone so can't keep it in the Config struct.

I briefly tried storing a reference to it but that quickly ran into lifetime issues.

So now I'm thinking of using OnceCell

Something like

static EXTRA_HIGHLIGHT_THEME_SET: OnceCell<Syntect::ThemeSet> = OnceCell::new();

Would that be agreeable? It's not a direct dependency, but some dependencies depend on it.
I'd be happy to replace lazy_static with once_cell too if that's desirable to keep number of dependencies down.

Could even move extra_syntax_set out of Config to a static as well for consistency. static EXTRA_SYNTAX_SET

Using it would look something like

impl Site {
    pub fn new(...) {
        let mut config = get_config(config_file);
        let extra_syntax_set = config.load_extra_syntaxes(path)?;
        let extra_highlight_theme_set = config.load_extra_highlight_themes(path)?;
        EXTRA_SYNTAX_SET.set(extra_syntax_set).unwrap();
        EXTRA_HIGHLIGHT_THEME_SET.set(extra_highlight_theme_set).unwrap();

I assume this is safe to unwrap because Site::new() is only called once (per run) but I might be wrong to assume that!

[drmason13]

I'm completely wrong to assume that. I've got something that works... the first time it builds a site.

[drmason13]

Now I have something working, it won't be able to "reload" extra highlighting themes without running serve again, but it works :)