Background
This issue assumes the context of the comments made in issue: catppuccin/catppuccin#2278 (comment)
I'm continuing the conversation in here to avoid valuable information being buried in a closed issue.
Description
I will provide a more explicit definition in the theme-making documentation/template for Yazi in the next few days - A Yazi theme that does not include a tmTheme file is considered an invalid theme, and each theme must be a directory.
- @sxyazi
Thanks for giving us a heads up! In regards to directory restructure, I think it then makes sense to have something like the following:
.
βββ assets
βΒ Β βββ latte.webp
βΒ Β βββ frappe.webp
βΒ Β βββ macchiato.webp
βΒ Β βββ mocha.webp
βΒ Β βββ preview.webp
βββ frappe
βΒ Β βββ theme.toml
βββ latte
βΒ Β βββ theme.toml
βββ macchiato
βΒ Β βββ theme.toml
βββ mocha
β βββ theme.toml
βββ README.md
βββ LICENSE
βββ ...
I understand that you'd like yazi themes to include the .tmTheme
files in the same directory since it would be invalid and cause further inconvenience for the user. One potential "solution" is via git submodules if @uncenter is happy with managing the additional complexity. The .tmTheme
files could be git symlinked into each directory, meaning the user could clone with git clone --recurse-submodules
and then copy the files? However, I don't really believe this is worth it.
Personally, I still think its fine including the theme.toml
files and telling users in the README to go download the .tmTheme
file elsewhere, of course not ideal in yazi's case but I'd really like to avoid the duplication of files in the organisation.
Β
The reason for making such a request is because I really love catppuccin and can't go a day without it. You might find it hard to believe that in earlier versions of Yazi, the color of catppuccin was hardcoded directly into the code, and it has appeared as the official theme until now. Therefore, I will be more stringent in my requirements for it.
- @sxyazi
I really appreciate how much you care about the theme, and I appreciate you being involved in this discussion. When it comes to decisions like the above, I'm looking at it from the perspective of the organisation as a whole.
Duplication of files ultimately harms the organisation overall as files may get updated in one place and not the other, and I'm okay with slightly inconveniencing the user's installation process in return for no duplicated files across repositories. I hope you can continue to understand my position on this.