-
-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support custom accent colour from the user & the full palette #411
Comments
Can you not set the accent color to say pink and then use |
I already thought of that. The problem is that I don't know which of the palette colors are being used for syntax highlighting. My uninformed guess would be that they probably all are, and I have no desire to mess with the syntax highlighting. If there is a named color in the palette that is definitely not being used, then I guess that would work, but even so it certainly seems less than ideal. |
Hey @mattlucock 👋,
We're all for customisation but I'd argue that it was an intentional or even implicit design choice as we don't expose that type of customisation API by default for any of our other 300+ repositories in the organisation. I'm willing to explore the idea of allowing the accent colour to be anything but I'm also wary at the same time of the extra complexity that it would add to the surface API. In the short term, I think it would be fine/trivial to add support for a custom hex code or the full palette as mentioned in #410 since that wouldn't be a breaking change. However, I can forsee that the introduction of a custom accent hex code will most likely bring about a future feature request where people want to have different accents per flavour, probably leading to a more complex API as shown below: "catppuccin.accentColor": {
"all": "red", // Named accent colour
"latte": "#000000", // Custom hex code
"mocha": "crust" // Named monochromatic colour
// Frappe & Macchiato would default to "red" as specified in "all"
}, Changing it to something like the above would be a breaking change and, at the moment, it's something that I wouldn't want to introduce into the theme. Of course, that may change but just speaking from my current state of mind. Especially in a codebase that unfortunately doesn't have any unit or integration tests (yet 🤞) With all that being said, I think it would be fine to allow a custom hex code to be the accent colour since it should be trivial. There might also be a larger discussion on whether or not we should in the first place.
Agreed, I'll make a PR clarifying this since it's technically true with the |
i'm concerned that the effort required to implement this properly isn't justified by its utility. we would certainly need to support different accents per flavour as a single colour for all four is not going to look good, and if we didn't implement it at first i can guarantee an issue will be raised for it in future. i am not personally willing to make a breaking change for the i will put some thoughts here for a potential design that i would consider accepting a PR for: "catppuccin.accentColor": "custom",
"catppuccin.customAccentColors": {
"all": "#FFFFFF",
"latte": "#000000"
} i'm currently leaning towards not wanting this, but if someone were to implement it (in any non-breaking way, not just the above suggestion) and request a review from me, i would give it a second thought. |
The readme says:
I think what the author meant to say was that you can choose any color from the Catppuccin palette as your accent color. Instead, it says that you can simply choose 'any color'. This is definitely not the case; it's clear from trying it that this doesn't work, and it's clear from the code that this doesn't work.
But I think I would like it to work. I want to use an accent color that isn't one of the options from the palette, and I would be happy to override the accent color in the same way that I'm overriding named colors such as
base
andmantle
. From the code, it's clear thataccent
is not a named color, but a variable that holds a named color. This strikes me less as an intentional design choice and more as an inadvertent limitation of the current implementation. Given that the theme explicitly allows colors to be overridden, it seems odd and contradictory that the scope for customizing the accent color is so limited. At the very least, I think the documentation should be clarified.See also #410
The text was updated successfully, but these errors were encountered: