RFC: improving styles with themes

[ThomasAdam]

In a recent discussion in the IRC channel for telescope, @omar-polo and I were talking about how we might improve some of the UI styles.

For example, it's not currently possible to add styling (bg and fg, attr, etc.) to the modeline -- something I know I'd like to change.

One suggestion we had was to introduce themes. Currently, this is achievable through separate config files but this approach is inflexible. Instead, the proposal would look something like this:

theme some_theme {
    style line.pre.end      bg color239

    style line.link {
        prefix "=> "
        fg color81
        attr normal
    }
}

Then it would be a case of having another config directive such as:

set theme some_theme

If people wanted to separate out these themes into separate files, we could introduce the include config option (stealing the implementation, more-or-less, from gmid ;)):

theme some_theme2 {
    include "themes/some_theme2"
}

Note that the path here (if it's not absolute) is considered relative to ~/.config/telescope or its XDG equivalent if that's defined. I'm not suggesting that such an include config option is limited to this theme proposal either.

So I think namespacing style to a theme block makes some sense.

We could even have a generic default theme which we ship.

theme default {
    style line.quote        attr dim normal
    style line.pre.start    bg color239
    style line.pre          bg color239
    style line.pre.end      bg color239

    style line.link {
            prefix "=> "
            fg color81
            attr normal
    }

    style line.compl.current {
            bg color50
            fg black
            attr normal
    }
}

If we were to allow inheriting themes so that users can create theme based off others, that might be interesting. Hence, I could then create a theme based on default:

theme my_new_default inherits from default {
    style line.link.prefix "<=> "
}

Such that the only thing in my_new_theme is the changed style of the prefix line -- everything else remains as inherited.

Not wanting to overload this idea too much -- at some point I'd like to see protocol-level styles as well. For example -- gemini is not a superset of gopher, and gopher has attributes I'd like to be able to style differently (such as a directory link). Currently, all links in gopher are rendered in gemini's style, which is misleading.

But we can tackle that problem separately.

[omar-polo]

I like this RFC. I think it's a nice idea to allow users to share theme as files and include them in the configuration, and also to "inherit" from existing themes to do some tweaks.

I'd just suggest to drop the style keyword inside the theme block. At this point I don't think it conveys much, it's just a keyword that needs to be always typed. (Assuming you don't have further ideas for stuff)

Not wanting to overload this idea too much -- at some point I'd like to see protocol-level styles as well. For example -- gemini is not a superset of gopher, and gopher has attributes I'd like to be able to style differently (such as a directory link). Currently, all links in gopher are rendered in gemini's style, which is misleading.

I have an idea on how to tackle this, and it would be by implementing "faces". I'll open an RFC for it, so that we can discuss and track it.

By the way, it's not a problem, but why opening this RFC on github instead of codeberg? I'm fine with receiving bug reports, feature requests and patches via any mean, but at least for our "official" discussion I'd like to have them (mostly) in one place. Since we're making PRs and reviews on codeberg, I thought we could have RFCs there as well.

[ThomasAdam]

I'd just suggest to drop the style keyword inside the theme block. At this point I don't think it conveys much, it's just a keyword that needs to be always typed. (Assuming you don't have further ideas for stuff)

No... I'd be happy with dropping the style keyword -- I left it in in case it felt necessary.

I have an idea on how to tackle this, and it would be by implementing "faces". I'll open an RFC for it, so that we can discuss and track it.

Ah yes. You mentioned that before. But as I understand it, that would also fit nicely into the theme block as well...

By the way, it's not a problem, but why opening this RFC on github instead of codeberg? I'm fine with receiving bug reports, feature requests and patches via any mean, but at least for our "official" discussion I'd like to have them (mostly) in one place. Since we're making PRs and reviews on codeberg, I thought we could have RFCs there as well.

Oh -- I only did that because you opened the discussion on gmid here, so I thought that's where I ought to open this suggestion. I would equally have used codeberg. Perhaps that's where we should standardise these things, and reduce how this "mirror" on GH is being used...

[omar-polo]

Oh -- I only did that because you opened the discussion on gmid here, so I thought that's where I ought to open this suggestion. I would equally have used codeberg. Perhaps that's where we should standardise these things, and reduce how this "mirror" on GH is being used...

It's not a problem :)

using the same platform has some little advantages: search is unified, can implicitly links one issue/pr from another, etc. So, while I'd still like to keep this mirror fully working (new issues and prs can be made -- I don't want to force people to make an account on forges they don't otherwise use), for "core" stuff I'd prefer to have a preferred choice to where look.