Open ThomasAdam opened 1 month ago
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.
I'd just suggest to drop the
style
keyword inside thetheme
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...
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.
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
andfg
,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:
Then it would be a case of having another config directive such as:
If people wanted to separate out these themes into separate files, we could introduce the
include
config option (stealing the implementation, more-or-less, fromgmid
;)):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 aninclude
config option is limited to this theme proposal either.So I think namespacing
style
to atheme
block makes some sense.We could even have a generic
default
theme which we ship.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
:Such that the only thing in
my_new_theme
is the changed style of theprefix
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.