Is there (or should be) a difference between color0 and background?

[explosion-mental]

Hey, I've made wallust with just enough color theory and the main behaviors of pywal. One of those behaviors is making background just a bit more darker than color0. However, generally (visibly), they are "the same", and thus if one uses color0 ad the font color for text, in a background with background color, the text becomes invisible. I don't think this, however, is the usual behaviors of terminals (at least by default?), and for ttys it should respect foreground (however, I don't touch much tty stuff either).

Since the issue is about a neovim colors, I thought you might know something about this.

This is from issue #60 of the wallust repository.

[RedsXDD]

Honestly I've always had that issue as well. Not only with wallust nor only with terminal applications, color0 always seemed to be the same as background on whichever application I tried or whichever wallpaper I used to generate the color palette. At some point I just gave up using color0 entirely and just started using darker/lighter shades of background instead. But generally speaking color0 seemed to "equal" background on anything (including GTK/Qt applications for example). So personally speaking I would say it's either a problem with pywal/wallust themselves or with the way human eyes perceive the difference between light shades better than the difference between dark shades (I am not a expert on that so take my word with a huge grain of salt).

[eylles]

is the luminosity, the greater the luminosity of a color the easier it is to distinguish the Δ change in color lightness so long as the saturation remains the same.

that is part of the theory on the hsl and hsv color spaces being a better way to describe color than the rgb color cube.

to have different shades of dark colors be distinguishable you have to make larger steps in lightness and saturation, a great example of that is the algorithm used in pywalfox, for which i conveniently got an implementation written in lua here as for the license all code there is under the apache 2 license, i would open a PR and add them myself but i'm currently on the process of rewriting my nvim config to lua after almost 6 years of having my config in vimscript when i was still using vim and not neovim.

yes, i've just began using the neopywal colorscheme, if you want i can "officially" endorse it on the pywal16 repo.

[RedsXDD]

I would really appreciate if that could be done 🙂

Have that said the idea i originally had was to create a github organization only for pywal related stuff (similar to catppuccin). Not sure how well that idea would work however, my plan was for each program supported by pywal to be have it's own separate repo containing templates not only for Pywal16 and Wallust but also for any other program that can do a similar color generation to them (like matugen) as well as possibly an additional shell script to help setup the integration for that program.

Perhaps it's too wild of an idea from my part but i guess that could make finding pywal support for X program easier than searching for a bunch of repos not only for that program but also for alternatives for Pywal itself.

[eylles]

well about that last part, that is lowkey why i have the pywal-extra repo, so that templates for programs, scripts and other miscelaneous stuff, like the very pywalfox algo ported to lua can be there, on that repo, as not every template should belong in the main pywal16 repo if you ask me, but rather only stuff to support window managers, terminals and the dmenu type of programs as has been historically the case.

[RedsXDD]

Well for now i am not really planning on working on that idea because i am more focused on improving Neopywal. But i feel like actually doing it would have a few advantages.

1. Searching for Pywal support for anything would be just as easy as searching "program X Pywal" and then one of the first results from the search would be the organization with a repo dedicated for the program X.
2. Since the organization would be focused not only on Pywal16/Wallust, anyone looking for support for program X for, let's say, matugen, would also be able find it in the organization.
3. Since every program would have their own repo, the integration for it could be improved with time, instead of being an (mostly) static one time solution found on the Pywal16 wiki or an random github repo that's generally maintained by only one person (e.g.: neopywal itself or zathura as another example).
4. Any project that aims to be similar to the original Pywal could just put a single link in their repository that goes to the organization. That would save time for them to list similar alternatives to their project (since everything would already be listed on the organization) and also would motivate them to make their own project somewhat feature compatible with Pywal (mainly talking about templates etc) so that their project could work with all the programs supported on the organization (again saving them time from writtin their own wiki etc).

[eylles]

yeh, at least with pywal16 it kinda needs to have it's own templates repo as the old master branch of pywal (unreleased) contained the ability to run functions like lighten, darken and saturate directly on templates, it wasn't until the first release tag of pywal16 that the functionality was "released", and honestly i don't advertise that functionality a lot since it has quite some jank that needs to be fixed... but i do put out templates using that functionality...