You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Below is what I have come up with to fix some color issues with lsd.
I am assuming that these changes could be rolled out along with the config files changes for changing colors.
This should let us fix most of the problems with color. There are some pieces that I still need to think over, but this is the general idea.
Just posting it here to get an opinon on what others think about this approach.
By default use only values upto 16 for colors. Will have to fix the non name blocks as well.
This will make sure user's terminal colors are respected even without user configuring anything.
Doing this however might case users who have not configured LS_COLORS to have a change in the colors for the output.
When changing the non name block colors, we might have to drop all that yellow as yellow is a really bad color for light backgrounds.
Below is a small tweak I was able to do to existing colors and have it work in light colorschemes.
Both the light and dark variants are off of the same configured colors and no lscolors.
Using orange/yellow is a bit risky however as most colorschemes will not have a usable color value associated to it, but this lets us stick to the existing colors.
This is available in better-light branch in my personal fork.
Another option would be introduce --color-theme flag with options dark & light and maybe even minimal (which will only color name block fully and rest with only black/grey shades).
This is available in colorable branch in my fork.
Documentation
Document using trapd00r/LS_COLORS for better colors and update screenshot in readme with trapd00r/LS_COLORS.
Or suggest using something like di=34:ln=35:so=32:pi=33:ex=31:bd=34;46:cd=34;43:su=30;41:sg=30;46:tw=30;42:ow=30;43 as the LS_COLORS value.
Might even be a good idea to ship default lscolors value as the above one instead of one from lscolors crate?
Configuring
LS_COLORS will let you customize name block.
config will allow customizing non name block colors (maybe even name in future as LS_COLORS is a tiny bit limited on colors)
Below is what I have come up with to fix some color issues with
lsd
.I am assuming that these changes could be rolled out along with the config files changes for changing colors.
This should let us fix most of the problems with color. There are some pieces that I still need to think over, but this is the general idea.
Just posting it here to get an opinon on what others think about this approach.
By default use only values upto 16 for colors. Will have to fix the non name blocks as well.
This will make sure user's terminal colors are respected even without user configuring anything.
When changing the non name block colors, we might have to drop all that yellow as yellow is a really bad color for light backgrounds.
Below is a small tweak I was able to do to existing colors and have it work in light colorschemes.
Both the light and dark variants are off of the same configured colors and no lscolors.
Using orange/yellow is a bit risky however as most colorschemes will not have a usable color value associated to it, but this lets us stick to the existing colors.
This is available in
better-light
branch in my personal fork.Another option would be introduce
--color-theme
flag with optionsdark & light
and maybe evenminimal
(which will only color name block fully and rest with only black/grey shades).This is available in
colorable
branch in my fork.Documentation
Document using trapd00r/LS_COLORS for better colors and update screenshot in readme with
trapd00r/LS_COLORS
.Or suggest using something like
di=34:ln=35:so=32:pi=33:ex=31:bd=34;46:cd=34;43:su=30;41:sg=30;46:tw=30;42:ow=30;43
as theLS_COLORS
value.Configuring
LS_COLORS
will let you customize name block.config
will allow customizing non name block colors (maybe even name in future as LS_COLORS is a tiny bit limited on colors)Related issues/PR
The text was updated successfully, but these errors were encountered: