v2.0.0 - Pre-Release Discussion

[sgoudham]

Hi all 👋,
I'm Hammy, one of the co-owners of the Catppuccin organisation.

This is the discussion post for our upcoming v2.0.0 release, which aims to align the syntax highlighting of catppuccin/nvim with other ports/code editors in the organisation.

So far, we've merged #804 and will be merging #902 to resolve some unexpected regressions in LSP semantic highlights. We're still working our way through the "main" languages so expect the main branch to receive more updates updating the syntax highlighting. Once we feel that it's ready - we'll release v2.0.0

Important

This discussion is a place for people to leave constructive criticism and feedback with regards to the above changes. I will absolutely not stand for any behaviour that falls outside of our Code of Conduct. This is an open-source project which people volunteer their free time, no one is actively trying to ruin your day.

Potential FAQs

I'll attempt to answer some questions that people may already have:

The treesitter highlights were fine, why are you changing them?

I'd like to preface this answer by saying that colours are, ultimately, subjective. Back when Winston (a previous co-owner) and I were starting to develop the VSCode port, we were interested in taking the syntax highlighting of Neovim and evolving it to be more semantically consistent.

We happened to agree that some highlights in catppuccin/nvim felt quite overbearing and, for lack of a better term, "rainbow puke" all over the screen. As a result, the upcoming changes may come across as "regressions" where text is preferred over an accent colour.

To clarify, I'm all for improving syntax highlighting to make easier to discern elements that are semantically meaningful, but I am not interested throwing all of our accent colours into all possible Treesitter captures.

Why change the highlights all at the same time, and why now?

In an ideal world, all of our code editors would be updated immediately as we decide on a change/improvement to the style guide. Unfortunately, that's not the world we live in.

VSCode happened to get more of the updates since we were using that port for majority of the changes, and we've slowly had a decline in maintainers for existing code editors so there hasn't been anyone updating our code editors on a regular schedule. Not to mention that no one was the maintainer of the neovim port for quite a while, resulting in quite a bit of tech debt making it hard to motivate anyone to test and review changes.

Some of the changes here don't even align with VSCode, Intellij, etc. Why?

The direct answer is that each editor has to make trade-offs depending on their syntax highlighting method, and on top of that, a lack of maintainers in some editors means that changes to the style guide haven't been propagated out.

These changes are to try and keep the syntax highlighting of Catppuccin across different editors feel more consistent and unsurprising. It's a hard balance to strike when trying to improve the highlights in different grammars, but also make it feel familiar across lots of different code editors. You may find that VSCode, Intellij, etc will receive some updates after we land v2.0.0 in this port.

Why the alignment with VSCode's Textmate, when Treesitter is more powerful?

I'd like to quote @uncenter from their comment as they put it quite well:

Tree-sitter is great and definitely more powerful than TextMate grammars. VS Code has actually been investigating switching to Tree-sitter, which is exciting progress I've been following. While Tree-sitter makes things easier and better for implementing language support, it doesn't make anything more or less possible for themes wrt. syntax highlighting - we've been able to refine the syntax highlighting implementation in VS Code just fine, evolved from the original syntax highlighting for Neovim in this very repository.

To expand on that, it is my personal opinion that while we can be more specific with lots of different Treesitter captures, that doesn't necessarily mean we always should differentiate it in colour.

The style guide feels quite vague, how are improvements/changes considered?

I will fully admit that our style guide needs a complete overhaul. This is something @unseen-ninja and I are looking into when time permits to turn it into something more detailed and specific.

Improvements/changes are effectively considered via issues/PRs on the catppuccin/catppuccin repository, but I highly recommend you engage with us in our official discord server to increase the likelihood of any contribution being accepted.

I have some thoughts around these changes, where can I leave feedback?

This discussion is the place to do so. If you feel like a different colour should be used for a highlight, please take the time to detail why. If the reasoning for a change boils down to a simple "I don't like this" with no other points then it has an incredibly low chance of being considered for any discussion.

Be civil, respectful and adhere to our Code of Conduct. Thank you.

Closing Thoughts

This repository is quite special to Catppuccin in many ways, with it being the first one to effectively kickstart the entire organisation. However, as time has gone on, catppuccin/nvim has always felt like the "odd one out" when it came to syntax highlighting. Of course, I do regret that we haven't been able to keep it up-to-date in incremental chunks, but such is the nature of open source.

I know some of you will completely disagree with the changes here, and will still prefer the highlights prior to v2.0.0 - I'd highly encourage you to make use of the custom_highlights API to configure the captures to your liking. We'll have a snippet in our official v2.0.0 release which you can copy/paste into that function to preserve the older syntax highlighting.

As always, thank you to everyone who continues to use, contribute to, and share Catppuccin!

[igorlfs]

Hello,

EDIT: this comment was made prior to #902 being merged and currently contains outdated information. I'll update it with all my up-to-date suggestions in due time.

EDIT 2: "due time" took a really, really long time

(I was originally gonna post this on #804, but it got locked)

(Check the edits for a broader context)

It's now been a little over 2 months since #804 was merged, and I'm here to "share my up-to-date suggestions". To start off, I'm glad the "lavender situation" got sorted out. Most of the comments on this thread as a whole regard this single point. That being said, I feel that some other changes also deserve some attention (which were in my original comment):

mauve was chosen to be the color for every keyword, including built-in types and operators. I guess prioritizing if a token should be considered a keyword or something else is completely subjective, but I feel like this change introduces some odd "discrepancies" (I guess some would consider them features?). For instance, when I use a type in any language, I'm more interested in the fact that I'm using a type and not that if the type I'm using happens to be a keyword¹.

If I'm annotating the type for a function in python, I'm more interested in the type itself, and to me, the following feels like a lackluster (a scenario where I'm using both built-in and user defined types), because a color that doesn't mean "type" is used:

Proposed solution²: yellow could be used for both built-in types and regular types. But for built-in types, it could be italic (related #944)

Again, I can see how this would be considered a feature, and I'm just not feeling it. In a subtle, but similar manner, the same problem affects operators. The following snippets are semantically "equivalent", but highlighted differently with the new theme:

Proposed solution²: I actually don't mind this one that much, I feel like that at the end of the day it's just a matter of opinion.

There are some other impactful changes (such as the tags), but I'm still on the fence about them, so I'll not elaborate for now (and tags aren't as ubiquitous). There's some ongoing discussion about the tags, check the replies. My proposal for the attributes is to use lavender (rationale), but for the tag names themselves, I don't have a solid suggestion - I just stuck with the old style.

---

To finish off, I'd like to share the overrides I've been using for these past few months. Fortunately, there aren't that many. Most just restore the previous style, but some are new:

return {
 ["@type.builtin"] = { fg = C.yellow }, -- For builtin types.

 ["@keyword.operator"] = { link = "Operator" }, -- For operators like "new", "or", "typeof"...

 ["@tag"] = { fg = C.mauve }, -- Tags like html tag names.
 ["@type.tag.css"] = { fg = C.mauve },

  -- My proposal for tag attributes
 ["@tag.attribute"] = { fg = C.lavender },

 -- Personal pet peeves
 ["@markup.raw"] = { fg = C.teal }, -- Do not highlight "non string" stuff as string
 ["@markup.list"] = { fg = C.sky }, -- Avoids a clash with the previous override
}

Additionally, I'm still a bit on the fence about @module, but I might stick with the new style, which is what I have been doing. For non treesitter stuff, I also reverted #899, but I'm willing to give it a second chance.

Footnotes

1. I personally disagree, but that's completely subjective. ↩

2. Not suggested initially. ↩ ↩²

[gabrielscaranello]

Hi. I'm testing the mainstream changes, and now things seem to be more consistent.
However, I tend to agree with @igorlfs observation regarding the replacement of lavender with blue. It can be confusing at times, but perhaps it's just a matter of adapting to the new colors.

[schemar]

It can be confusing at times, but perhaps it's just a matter of adapting to the new colors.

For what it's worth, you can always specify overrides to get certain highlight groups, built-ins, etc. highlighted in your color of choice.

See the documentation on customization for details.

Personally, I prefer the reduction of colors. I think it's good to default to a simpler approach and then let users who want more rainbow specify that themselves. You can also share your custom colors and highlights in a discussion here. Maybe even to revert to the old colors with custom colors and highlights 🤔

I have reduced the number of colors in my own adaptation of catppuccin as well, as I thought it was too much and meant some colors are too similar, anyway.

[gabrielscaranello]

Once the style guide is ready, it might be worth adding a section with the settings to get the 1.x color scheme.
This will make it easier for those who want things the way they were before.
Something similar to the code in this comment (#804).

[gabrielscaranello]

You can also share your custom colors and highlights in a discussion here.

Personally, I don't tend to customize things too much. I prefer the experience to be as close as possible to what the developers intended.

[igorlfs]

Hey, I'm back!

I've merged #902 which should resolve some of your comments above, and I think we can talk further about the built-in types

Got it! I'll update my comment to avoid any confusion. Regarding the bult-in types, I don't have a specific suggestion (other than using yellow). In fact, I think there's not much else to go.

The changes around tags may honestly be more subjective then related to semantics since I vaguely remember just trying out new colours with Winston to see what we can align on for those "data languages" like json, yaml, toml, etc.

Ah, that's nice to know. After a little more usage, I came to the conclusion that I prefer the old style for tags. For this topic, I do have a proposal.

To me, special casing "data languages" is a minus: it introduces some inconsistencies. Currently, for "regular languages", properties don't have any highlighting, whereas in "data languages" they "suddenly" do. Take the following snippet, for instance:

The old style achieved this consistency with lavender, which was used everywhere:

I don't see an argument against using lavender. As pointed out by @andreihh, it barely adds to the "rainbow pukeness", but it's still distinguishable enough to let users know that something isn't a regular variable. The style guide has no mention of a lavender "language default", I guess it could "fill" such a gap without introducing too much noise.

To further enhance this proposal, I suggest updating the color for tag attributes to also be lavender. This may sound like it comes out of nowhere (since it differs from both the new and the old styles), but my rationale is that, defining attributes for a tag resembles defining properties for an object. Compared to the old style, this avoids using ("wasting") another color (teal) and compared to the new style, it avoids "overloading" yellow, leaving it exclusively for types (and alike). Now, to elaborate a little further on this topic: types and tag attributes can "inhabit" the same file, as is the case for HTML-like languages (e.g., Svelte, which is on the "main" list).

Leave it to Neovim users to get annoyed at the mention of VSCode though 😄

Just to be clear, I'd be just as upset if some other tool was used as "the single reference". I'm aware this comparison ended up causing such a commotion (someone even made a post on the neovim subreddit), but neither my original comment nor any of the follow-ups intended to fuel such discussion.

As a closing note, I do agree with Gabriel that the focus of the discussion should be precisely the default experience.

[Ethee]

So I'll start by saying I can totally understand your motivations for making these changes. The goal of being logically consistent across your project is a fair one, however you've effectively just alienated a number of your users for absolutely no reason. Allow me to elaborate. As you say, color preference is entirely subjective, not everyone here will agree on the same reasons of why they like one feature over another. However, we all decided to make this our color scheme for one reason or another. By completely overhauling the color scheming rules you've effectively defined an entirely new schema, whether you accept that or not.

You even admit that you're not consistent in your own style guide, so maybe that should have been decided first before propagating to other projects and changing the way the people who use your project get to see their own code. I chose this color scheme because I LIKED the "Rainbow puke all over the screen" and just telling me to use some overrides to change your project back to the way I expected it to work in the first place is just a slap in the face. If you want to make these changes, either do it under a separate project or add a toggle, because I know I'm not alone in the fact that you've totally wonked my brain here.

Color scheming in coding isn't about being able to identify 'oh this is a variable because it's blue' its about being able to read your code at a glance, and you've just made readability 10x worse with this.

I'll be switching to a new schema I guess, because it very much seems like you have already made up your minds on going forward with this. I just really hope that's not the case because I really liked how this used to look.

[sgoudham]

@Ethee

however you've effectively just alienated a number of your users for absolutely no reason

I'll have to disagree with you on this statement. We haven't done this for "absolutely no reason" but rather to try and make sure people using Catppuccin across different editors have a consistent experience. catppuccin/nvim, in it's current state, is quite out of line with our other editors and so we're trying to get some changes applied to finally align it more towards what already exists.

You even admit that you're not consistent in your own style guide, so maybe that should have been decided first before propagating to other projects and changing the way the people who use your project get to see their own code.

The style guide that we have is a living evolving document, having full compliance with the "style guide" is effectively impossible (which is also why I prefer the term guide instead of something like "specification")

Majority of the highlights that you're seeing here have been adopted/stable in other editors for many months/over a year. Of course, due to different syntax grammars it cannot be 1:1. For example, our Notepad++ port is much more aligned with VSCode than Neovim.

I chose this color scheme because I LIKED the "Rainbow puke all over the screen" and just telling me to use some overrides to change your project back to the way I expected it to work in the first place is just a slap in the face.

As I mentioned in my original comment, I totally understand that people will still like the older highlights. But, I'll have to disagree with you here because by no means do I think our approach is a "slap in the face".

In my opinion, a "slap in the face" would be us changing these highlights, pushing to the main branch, releasing it as v1.12.0 or v1.11.1 and not acknowledging it at all. Personally, I feel like I have tried my best to ensure we make these changes in a way that respects the user the most (i.e. creating a breaking v2.0.0 release, creating this discussion for feedback, etc)

There are a few options available to you if you wish to keep the current highlights:

1. (Recommended) You could make use of our custom overrides API to effectively revert the highlights. This will largely be a "set and forget" once we provide the snippet to do so.
2. You could pin the project to the v1.11.0 release.
3. You could soft fork the repository, reverting the highlights but ensuring that you're still getting changes outside of them.

If you want to make these changes, either do it under a separate project or add a toggle, because I know I'm not alone in the fact that you've totally wonked my brain here.

We're already lacking in experienced/interested maintainers for 1 project so trying to sync 2 projects is simply a non-starter. I'm pushing back on the addition of a toggle because it's not consistent with any of our other editors to keep older versions of their syntax highlighting around.

Color scheming in coding isn't about being able to identify 'oh this is a variable because it's blue' its about being able to read your code at a glance, and you've just made readability 10x worse with this.

I'm really sorry but I don't understand what you mean here. The main objective of semantic highlights is to allow highlighting of code in a way treesitter cannot fully capture which, in theory, should be better at helping you read the code at a glance. We want to make sure that we are semantically consistent, which I understand to be against your personal preference.

---

@yavorski @andreihh

Thank you both for your thoughts/feedback. The introduction of @property to text happened a long time ago while developing the VSCode port and there was some subjectiveness to it for sure.

That being said, I find myself agreeing with @yavorski that it's a little unfortunate that Lua files like the example given are pretty much only text and I have to admit that if any colour was to be used for properties, it would have be something as subtle/similar to text like lavender @andreihh

I'm going to discuss this further with the rest of the maintainers / other co-owners to see if keeping @property as lavender is for the best, as well as updating VSCode to be the same (and our other editors where possible) Although, I'd currently quite like to make sure tags in languages like html, json, yaml, toml, xml, etc are kept as blue.

Please feel free to join our discord if you want to collaborate a bit more in real-time!

[schardev]

if keeping @property as lavender is for the best

Honestly, I do think it’s for the best. Just looking at the screenshots below, it’s immediately obvious which ones are properties and which ones are functions.

Before	After

[uncenter]

Your screenshot on the right does not appear accurate. Was that taken on the latest main branch? Non-function properties being the same as function properties was a bug caused by semantic tokens fixed in #902.

[schardev]

Hey, sorry my bad! On the latest branch I have this:

Before	After

I'd still prefer the lavender version, but that's subjective I guess.

[Ethee]

I'll start by saying the tone of my original message was a little aggressive. I didn't realize how much this change was going to bother me. So for that I apologize.

There are a few options available to you if you wish to keep the current highlights:

1. (Recommended) You could make use of our custom overrides API to effectively revert the highlights. This will largely be a "set and forget" once we provide the snippet to do so.

I decided to go with this route for now using the overrides you provided in #804. If anyone like me had an issue with their React Typescript html tags not changing you'll also need to add: ["@tag.builtin"] = { fg = C.mauve }

@sgoudham

I'm really sorry but I don't understand what you mean here. The main objective of semantic highlights is to allow highlighting of code in a way treesitter cannot fully capture which, in theory, should be better at helping you read the code at a glance. We want to make sure that we are semantically consistent, which I understand to be against your personal preference.

My point here was simply that you've decided to go with consistency over improvement for something that cannot be consistent. I feel like @yavorski's example makes that fairly obvious. I get that this is a 'best effort' attempt, I get your motivations for doing it. Like you mention, I just don't like it, and I know I'm not alone. Is what it is though, if anything you've pushed me to make some personal improvements for the sake of reading my code easier so thank you.

[villekivela]

There is a bit of discrepancy in angular decorators with vs code and nvim, first is vs code.


edit: ["@attribute.typescript"] = { fg = mocha.blue, style = { "italic" } }

[looshch]

i’m really disappointed, i’m donating a buck a month—not much but 12$/year/user for a color scheme sounds fair to me—because i appreciate your efforts, it’s a really great theme for neovim and i wanted to support you to keep it stable and up-to-date with the latest neovim changes. But this update makes the color scheme so much worse and forces me to find another theme, and obviously stop supporting you. That’s a real shame

[sgoudham]

i’m donating a buck a month—not much but 12$/year/user for a color scheme sounds fair to me—because i appreciate your efforts, it’s a really great theme for neovim and i wanted to support you to keep it stable and up-to-date with the latest neovim changes.

Thank you very much for the kind words and for your donation(s), it's incredibly appreciated!

I just want to clarify something regarding the donations generally. As per the description in our GitHub Sponsors and Open Collective pages, the funds are intended for upkeep of our web presence, infrastructure and other community endeavours that come up (domain renewals, email server, self-hosted discord bot, etc)

We cannot and do not promise that our ports are "stable" and "up-to-date" due to donations coming in. Keeping the ports maintained is purely down to community involvement/interest/effort.

I don't want anyone thinking that donations = maintainers are "paid" to work on the colourscheme. While I've thought about donations going towards maintainers before, I don't believe we can implement it in such a way that's reasonable and fair.

But this update makes the color scheme so much worse and forces me to find another theme, and obviously stop supporting you. That’s a real shame

This update has not been released yet so it's liable to change, evident by the discussion and feedback above. For what it's worth, the discussions that @backwardspy and I are having are actually trending towards keeping lavender and standardising that in our style guide, see #905 (cc: @igorlfs @andreihh)

I wouldn't want to introduce this type of "breaking" change again so I think it makes sense to standardise as much as we can right now.

All that to say, I completely understand your decision to stop supporting us, but I'd encourage you to wait and try the actual tagged release before making that decision. Thanks!

[looshch]

hey @sgoudham, hope you are having a great day so far!

the funds are intended for upkeep of our web presence, infrastructure and other community endeavours that come up

I don't want anyone thinking that donations = maintainers are "paid" to work on the colourscheme

those are really valuable clarifications, really appreciate it!

the discussions that @backwardspy and I are having are actually trending towards keeping lavender and standardising that in our style guide

this is really promising, hope eventually it will become the final decision!

also thank you for linking #905, that’s delightful to learn how important the users’ feedback is for you guys!

I wouldn't want to introduce this type of "breaking" change again so I think it makes sense to standardise as much as we can right now

awesome!

I'd encourage you to wait and try the actual tagged release before making that decision

ok, more than happy to go this route!

thanks a ton for spending time and explaining the current state of things to me, i acknowledge that’s not something to be treated as for granted!

[sigthror]

I generally agree with Looshch. The new scheme for Go is much worse; having the same color for package names and structs is quite confusing.

[nick22985]

Personally the updated colours I dislike and for me makes it harder to read things for html, javascript, typescript and vue (i havn't used the other languages I code in with it yet so cant say anything about the others as of yet). Understand that it is not the final version yet tho so will see what it comes to but currently I have reverted to the old colours using #804 (review)

It also might be just need some time to get use to the new colors as I have been staring at these colour for 4 or 5 years now.

[sgoudham]

Sorry for the wait on an updated response regarding the v2.0.0 release, I've been prioritising other areas of my life over OSS.

I've merged #905 earlier today as per the feedback from the users here, so lavender will be around to stay.

The final thing that I'd personally like to resolve before pushing ahead with the release is to revsit the style guide for HTML/CSS since @tag and @tag.attribute are now blue and yellow respectively:

nvim/lua/catppuccin/groups/treesitter.lua

Lines 134 to 136 in e79d09f

	["@tag"] = { fg = C.blue }, -- Tags like HTML tag names.
	["@tag.builtin"] = { fg = C.blue }, -- JSX tag names.
	["@tag.attribute"] = { fg = C.yellow, style = O.styles.miscs or { "italic" } }, -- XML/HTML attributes (foo in foo="bar").

@igorlfs's proposal on letting @tag.attribute be lavender is quite interesting to me, which I'll try out. I'm also interested in seeing what colours are inherited if those overrides aren't present. Happy to listen to other users if they have an opinion here.

Thanks for the continued engagement here and we'll make sure to release v2.0.0 with some detailed migration documentation when the time comes.

[yavorski]

Can you please consider making headings content different from the heading tag.
Could be lavander as well, but I don't mind something else too... It's too hard to distinguish between the the text and the tag right now because they are just blue?

[sgoudham]

The text inside the tag shouldn't be blue, I'd say that goes against expected behaviour of it being text like other editors so I'll take a look.

[igorlfs]

Hey @sgoudham,

I was gone for a while, but I finally took the time to update my original comment with my "final suggestions".

I must confess I felt a bit overwhelmed with this thread and I can fully empathize with any stress this migration may have caused.

Once again, thanks to you and every other maintainer for the amazing project!

[looshch]

any update on the progress or ETA?

[looshch]

got it—thank you for such a prompt reply, @comfysage! Happy (upcoming) new year!

[comfysage]

happy new years to you too @looshch !
last thing on the checklist is the removal of vim support then we're ready to ship!

[looshch]

any update?

[vollowx]

As discussed in Discord we are going to release before this weekend @looshch

[looshch]

@vollowx that is fantastic news, thank you and @comfysage for making the final push!