I came across all of these issues and many more trying to make a good light color scheme for my systems. Two interesting findings I did not see discussed:
1. It makes sense in retrospect, but I was very surprised at how much more subtle light themes are compared to dark when viewed on different screens; of course their hardware and software configs lead to variations on the color output, but light dominant changes are perceived so much more drastically than dark ones. This is a serious issue if you will be porting your theme to computers with a variety of screens and configurations.
2. Occasionally, you need to drop to a linux or bsd console with very limited support for fonts and fancy colors. Then your `fd` and `exa/lsd/whatever` may be unusable and annoying, especially if you have mapped the latter to `ls`. I managed, after a long struggle, to get a working fbterm in my system to get decent terminal features without X, but fbterm has its own issues. You need to account for this use-case, especially when configuring vim colorschemes: make sure that you have a fallback theme for a feature-poor console or you have really practiced typing vim commands blind :D
Edit: here is a screenshot of my stylized fbterm screen, obviously not for serious work, but meant to demonstrate what you can do without X: https://i.imgur.com/RbDRgtD.png
> I was very surprised at how much more subtle light themes are compared to dark when viewed on different screens.
This does not surprise me. I do analog black and white printing (from film) and it's a well known thing that our eye is much better at detecting subtle tonal changes in light areas of a print than darker ones. For this reason, a lot of the time in tweaking the right exposure and contrast for a print is spent to make those hightlights look "just right". I don't print digitally, but I am sure the same principles will apply there too.
> Occasionally, you need to drop to a linux or bsd console with very limited support for fonts and fancy colors. Then your `fd` and `exa/lsd/whatever` may be unusable and annoying, especially if you have mapped the latter to `ls`.
Normally you should be able to rely on a properly set TERM variable [1], and CLI utilities should respect the capabilities they can gain from the TERM variable.
Sadly, a lot of "modern" CLI tool frameworks - particularly those written in JavaScript - tend to ignore this.
I had a recent experience trying to show a large number of data series by different colours on a plot in Excel.
I found the best option for easily distinguishing a large number of colours was the monochromatic spectral "rainbow" colours on a black background (there's also a setting to make the data points have a bit of "bloom" aura in the same colour so they look like dots of light).
It makes sense from a colour saturation perspective (i.e. signal to noise ratio across the spectrum) that a black background is better.
You can pretty much have 10 different colours
EDIT: Another benefit is it conveys "sequence/order/distance" information: yellow is between red and green; orange is between red and yellow, etc. It's easy to subdivide and interpret how "close together" two colours are.
> Occasionally, you need to drop to a linux or bsd console with very limited support for fonts and fancy colors. Then your `fd` and `exa/lsd/whatever` may be unusable and annoying, especially if you have mapped the latter to `ls`.
I just did a check on my NixOS system there and the console seems fine? The ANSI blue on black for directories in eza is a bit... meh, but it's perfectly readable and the same is true for the default colour scheme for ls on MacOS terminal
Most terminal emulators ship with a garbage default colour scheme. So change that.
Personally I'm a fan of Solarized (specifically dark, but I like their light theme too). However even if you don't like Solarized, there are plenty of other themes that are readable with any colour against the default backgrounds.
Step 2:
Avoid any CLI tool that uses escape sequences for 8bit or 24bit colours by default. This might be an unpopular opinion, but I actually consider that as user hostile. Reason being: I've already chosen a the best terminal colour scheme for my readability requirements (remember, this will differ for different people). Having a developer override that because they fancy themselves as a pseudo-designer is not helpful. By all means, they can have an option to enable themes in their tool if they wish, but that should be opt-in, not the default.
As someone who spends most of their life in the terminal, following those two rules is enough to provide a consistent and easy terminal reading environment with almost-zero configuration overhead.
I think the real problem is that we indulge developers using 8bit and 24bit colour escape codes.
> By all means, they can have an option to enable themes in their tool if they wish, but that should be opt-in, not the default.
This touches on the problem of good defaults. If the user has to configure it then the user must know that it is configurable and then do it. This is a serious hurdle and only a tiny fraction of users will do it.
Over the years I've come to the conclusion that you must throw your new features into the face and shove good defaults down the throats of users, otherwise these feature are hardly used.
8bit and 24bit colors are already opt-in and you can configure it. Your TERM and COLORTERM environmental variables determine if a (well behaved) terminal program will use those colors.
Solarized Dark, specifically, is not well-suited for terminal use, because the author has assigned "bright black" to nearly the same color as the background. Many applications expect that 'bright black' text will be visible against the background. See here for many examples: https://github.com/altercation/solarized/issues/220
Nearly all other colorschemes represent 'bright black' as a gray color, which is readable against the black background.
> themes that are readable with any colour against the default backgrounds.
Yes, but then there are applications that set both the text and background colour. For example pamix sets the background to black, or tmux's statusline, or ngrok. And you end up in a rabbit hole trying to deal with that.
>> Avoid any CLI tool that uses escape sequences for 8bit or 24bit colours by default.
I was going to point out that the author never takes a step back and asks "What would be the best way to handle this?" The problem there is we have to define what "best" is. IMHO that involves a number of principles. My preferences are:
1) Any user customization should be in one place.
2) The impact on programs should be minimal (in LoC for example).
Both of those suggest the solution belongs in the terminal.
IMHO it starts with terminal programs having sane default colors. What that means is fuzzy, but so is this whole discussion. IMHO colors should follow the "standard" so that blue is still recognizably blue. But consideration should be given to the common forms of color blindness - for example I have a hard time reading pure red on black (adding a bit of anything helps this, don't just use ff0000).
Once terminals get fixed to have sane defaults, CLI programs should use those 16 standard colors. Any attempt to use 24bit here is either saying "I give up on getting those terminal folks to offer sanity" or it's saying something like "I know best", but either way users end up with N programs they have to configure. Lets not define themes in cli apps OK? Remember, this is my answer to "what would be the best way to handle this?"
I have similar thoughts when it comes to web sites and fonts. Present content in HTML so users can configure how they want to see it. Similar for page formatting - it's not a magazine layout, let it flow.
Also stuff in desktop software. IMHO Wayland compositors should remember window placement. It was stupid for every X program to store and restore its window position. Wayland says knowing about the environment is a security issue (and I agree) but then it becomes the DEs job to handle this memory. It also unburdens ALL the apps from having code for this.
There are other areas where that question comes up "Where in the software stack should this thing be handled?" Whatever your opinion, I believe you should start by answering the questions around that word "should". What are the goals in selecting where a thing gets handled? My answers always lean toward simplicity and maintainability. What other principles might I adopt to answer these questions?
Avoid any CLI tool that uses escape sequences for 8bit or 24bit colours by default.
How difficult is this in practice?
(Julia's article mentions this idea too without going deeper into the struggles)
A related topic is: Do terminal color schemes only concern themselves with the 16 base colors or do they also meddle with the RGB and greyscale parts. I mean you could also adapt the 8bit and 16bit colors to your readability requirements.
Step2: do agree with the fact someone making a CLI tool should respect user preferences. it's also much easier just not to use the sequences in the tool so I don't get why people would do that in the first place :S.
Step 1: I think here maybe the default setting should be solarized-dark/light on terminals. It's honestly a good and sane default. It's purpose built to be less hostile on the eyes in my opinion, which should likely be what's aimed for in a default setting... the themes and colors are there for people who like to stare at their terminal all day (if you only use it once or twice then you don't care about what color it has) so it should be eye-friendly defaults. if people want to muck about changing it to their own custom theme they won't be bothered about defaults anyway since they will immediately customize it.
I personally hate the fact I even need to swap a theme, or download and reformat some Xresources file tediously (while looking at godawful colors in the process!). I just want my eyes not to burn.. don't care what colors yield that result.
Would be good to check colours (if you're someone who picks colours) against the new APCA algorithm (Advanced Perception of Colour), which will supersede the existing x:y one in the upcoming WCAG 3.0 (which may take a few years yet). APCA takes font size, weight, foreground/background, and even apparently ambient light/surroundings and intended purpose into consideration. It would be neat if terminal emulators could use the device's light sensor to optimize the contrast based on environmental factors.
I've actually done this manually for my current terminal color scheme, because I could not find a single premade theme that satisfied my personal contrast requirements for all the ANSI colors.
And then we have the absolute mad men that just want to disable colors altogether[0]. I am tempted to try it myself, but I also like the pretty colors.
is my only vim configuration because terminal color sets were designed by computer programmers and electrical engineers and other people who don’t understand that the important thing about colors is not the colors but the brightness.
If you get used to monochrome terminals, you'll start to find that most colours are distracting and attention-getting. I wonder if there's a correlation between those who don't want colour in their terminal and those who have a very strong adblocker and/or extensively use reader mode in their browsers.
Color sequences are not portable and known to break things (e.g. Jupyter sessions crashing due to colored pytest reports) and nothing but a liability if you're just piping the output. I think it's more about having the option.
Especially coding, I find almost all coloring to be distracting and counterproductive. Doubly so when I'm bouncing back and forth between Linux ans Windows. Many tools' default use of color borders on (or crashes head on into) unusable.
Some tools offer a --color=never option, and a good number respect NO_COLOR. Unfortunately, not all do, and even those that purport to assume that those modes will only be used for use in pipelines, programmatic interfaces, and such. That leads to all sorts of unfortunate behavior.
They have a consistent color scheme concept of semantically significant color temperature, while leaning warm to save your eyes from staring at so much blue light. Comes with alacritty colorscheme
I was using "script" command to record my interactions on the terminal and with colors, it was a mess. Pretty sure there are other legitimate use cases.
I've wanted to use a light theme for my terminal for a long time, but I've always given up since there are just too many programs that use custom (non-ANSI) colors that are optimized for a dark terminal background. For some of those programs, the colors are configurable, but it seemed too much of a hassle to configure every single program. So now I'm just using a dark terminal background, but with a hand-picked ANSI theme where all the colors have a sufficient contrast ratio for me and also get a pass on APCA / WCAG 3 contrast checkers. I'm happy with it. :)
For some of us with higher-order visual aberrations, dark mode is a non-starter. (The converse holds for some people with cataracts.) The OSC 11 control sequence lets a program determine the background color, but few bother. Usually, someone just thinks yellow warning messages look cool, and that's the end of it.
That also leads to problem 12: Certain popular terminals that default to setting TERM=xterm256-color while not being xterm-compatible.
Edit: I just came across `xtermcontrol`, which can abstract the background check in scripts, and is in all the major package managers.
I was for a while faking a 16-color terminal without support for 256 colors just to avoid this configuration hell. I also tried https://no-color.org/ because I’d rather have no colors than bad colors.
These days I just gave up and manually configure most apps to use ANSI colors (e.g. fzf etc have command switches for that), and let Vim and Emacs be the only non-ANSI apps which are instead set to match the colorscheme I use in the rest of the terminal. (Although stuff like vim-dim let’s you go one step further if you want.)
I've been using a lightly customised version of the FlatUI colour scheme for around a decade and really haven't run into any situations where it's caused issues:
I've used Apple's Terminal for a long time, way back when there was a set of color schemes called "Terminal Fructose" that was nice, I would have different colored backgrounds for different tasks. Apple at some point built that in with their themes.
However, Apple have languished with their Terminal support, they don't to >256 colors and some of the other more modern stuff is lacking and it doesn't really work with a Neovim+LazyVim setup.
I've been trying to find a "better" terminal and have bounced around between iTerm2, Kitty, Alacritty and Wezterm, but while they all are more "modern", I find that none of them seem to have that basic "New Window with Profile ..." option that lets me quickly open windows with different background colors/themes (at least without some screwing around).
Currently settled on Wezterm, mostly because it also works on Windows and I can share my wezterm.lua configuration (I should note that Windows Terminal is actually pretty good too). I still do find my self running Apple Terminal for quick things (e.g. using python3 as a REPL to do math or testing hex/binary stuff out etc).
I stuck with Wezterm for two reasons: 1) I can share the config across multiple platforms easily 2) Lua for configuration.
There are a few things I miss from iTerm2 (mostly mouse related), but otherwise it took me a few evenings to configure it to my liking (cmd-n opens a new window at the default dir, not the current one) and I've been a happy user since.
Not just terminal, but be it Neon signs or LED name boards, blue is the toughest on eyes during night time. It's always blurry from a distance, and can't even focus on it. I have seen big businesses putting up huge name boards in blue lights, and I think how they can spend a lot of money without even realizing that people can't read it.
I have automatic light/dark mode tied to the daylight cycle on my laptop and the amount of colour emitting applications which break when I turn on light-on-dark mode is astounding.
If you are writing a command line tool and you absolutely insist it must have colours then stick to the ANSI 16 colours or allow end users to customize the colour scheme.
I've reached a point where having well-coordinated colors in my terminal just doesn't concern me, I find it to be a waste of time now. I used to be all about finding the perfect scheme, with the perfect terminal font, cool transparency and whatnot, now I just don't really care. I have more interesting things to work on. Whatever, if you want to, you do you.
Maybe because I've had to work on enough remote consoles without any, or limited, color support where I'm more concerned about the problem at hand than which shade of blue is being output for directories. Ok, I'll admit I adjust the default apple terminal 'pro' scheme colors a bit, adding a bit of contrast to the background because I'm in it all day, but beyond that, nothing. I find coloring has little to no positive effect on my productivity, and in some instances, hinders it. No colors on ls, I actually get a bit annoyed when color escapes reach stdout via logs now, hah. Hell, that extends even to my $PS1. I've never bothered to update it on this system. Crotchety, grizzled ops person perspective maybe?
A big problem is that, even when you ignore 256 and true color support, and limit yourself to the 16 color palette, there’s no consensus on whether the 16 colors are backgrounds or foregrounds. Some CLI write text in foreground color over color_x, while others do it with background color.
I used to spend all this time choosing the colors on my terminal. Now I just use white background black text. No glare in daylight with the glossy laptop screens we all have now, and if you are working at night you can use something like f.lux to eliminate eye strain.
Terminal colors are tricky, which is why I outsource all of my colors to more capable people. Personally, I like Catppuccin (https://github.com/catppuccin/catppuccin)
Most of this just boils down to people designing themes not understanding accessibility when it comes to color. If they followed the WCAG Color Contrast guidelines it'd be a mostly non issue.
[+] [-] ykonstant|1 year ago|reply
1. It makes sense in retrospect, but I was very surprised at how much more subtle light themes are compared to dark when viewed on different screens; of course their hardware and software configs lead to variations on the color output, but light dominant changes are perceived so much more drastically than dark ones. This is a serious issue if you will be porting your theme to computers with a variety of screens and configurations.
2. Occasionally, you need to drop to a linux or bsd console with very limited support for fonts and fancy colors. Then your `fd` and `exa/lsd/whatever` may be unusable and annoying, especially if you have mapped the latter to `ls`. I managed, after a long struggle, to get a working fbterm in my system to get decent terminal features without X, but fbterm has its own issues. You need to account for this use-case, especially when configuring vim colorschemes: make sure that you have a fallback theme for a feature-poor console or you have really practiced typing vim commands blind :D
Edit: here is a screenshot of my stylized fbterm screen, obviously not for serious work, but meant to demonstrate what you can do without X: https://i.imgur.com/RbDRgtD.png
[+] [-] sricciardi|1 year ago|reply
This does not surprise me. I do analog black and white printing (from film) and it's a well known thing that our eye is much better at detecting subtle tonal changes in light areas of a print than darker ones. For this reason, a lot of the time in tweaking the right exposure and contrast for a print is spent to make those hightlights look "just right". I don't print digitally, but I am sure the same principles will apply there too.
[+] [-] mschuster91|1 year ago|reply
Normally you should be able to rely on a properly set TERM variable [1], and CLI utilities should respect the capabilities they can gain from the TERM variable.
Sadly, a lot of "modern" CLI tool frameworks - particularly those written in JavaScript - tend to ignore this.
[1] https://www.gnu.org/software/gettext/manual/html_node/The-TE...
[+] [-] HPsquared|1 year ago|reply
I found the best option for easily distinguishing a large number of colours was the monochromatic spectral "rainbow" colours on a black background (there's also a setting to make the data points have a bit of "bloom" aura in the same colour so they look like dots of light).
It makes sense from a colour saturation perspective (i.e. signal to noise ratio across the spectrum) that a black background is better.
You can pretty much have 10 different colours
EDIT: Another benefit is it conveys "sequence/order/distance" information: yellow is between red and green; orange is between red and yellow, etc. It's easy to subdivide and interpret how "close together" two colours are.
[+] [-] jve|1 year ago|reply
[+] [-] wolfspaw|1 year ago|reply
Really good colors and organization of the terminals, it would be great for serious work too in my view =p
[+] [-] weinzierl|1 year ago|reply
[+] [-] Macha|1 year ago|reply
I just did a check on my NixOS system there and the console seems fine? The ANSI blue on black for directories in eza is a bit... meh, but it's perfectly readable and the same is true for the default colour scheme for ls on MacOS terminal
[+] [-] hnlmorg|1 year ago|reply
Step 1:
Most terminal emulators ship with a garbage default colour scheme. So change that.
Personally I'm a fan of Solarized (specifically dark, but I like their light theme too). However even if you don't like Solarized, there are plenty of other themes that are readable with any colour against the default backgrounds.
Step 2:
Avoid any CLI tool that uses escape sequences for 8bit or 24bit colours by default. This might be an unpopular opinion, but I actually consider that as user hostile. Reason being: I've already chosen a the best terminal colour scheme for my readability requirements (remember, this will differ for different people). Having a developer override that because they fancy themselves as a pseudo-designer is not helpful. By all means, they can have an option to enable themes in their tool if they wish, but that should be opt-in, not the default.
As someone who spends most of their life in the terminal, following those two rules is enough to provide a consistent and easy terminal reading environment with almost-zero configuration overhead.
I think the real problem is that we indulge developers using 8bit and 24bit colour escape codes.
[+] [-] bhaak|1 year ago|reply
This touches on the problem of good defaults. If the user has to configure it then the user must know that it is configurable and then do it. This is a serious hurdle and only a tiny fraction of users will do it.
Over the years I've come to the conclusion that you must throw your new features into the face and shove good defaults down the throats of users, otherwise these feature are hardly used.
8bit and 24bit colors are already opt-in and you can configure it. Your TERM and COLORTERM environmental variables determine if a (well behaved) terminal program will use those colors.
[+] [-] fwip|1 year ago|reply
Nearly all other colorschemes represent 'bright black' as a gray color, which is readable against the black background.
[+] [-] arp242|1 year ago|reply
Yes, but then there are applications that set both the text and background colour. For example pamix sets the background to black, or tmux's statusline, or ngrok. And you end up in a rabbit hole trying to deal with that.
[+] [-] phkahler|1 year ago|reply
>> Avoid any CLI tool that uses escape sequences for 8bit or 24bit colours by default.
I was going to point out that the author never takes a step back and asks "What would be the best way to handle this?" The problem there is we have to define what "best" is. IMHO that involves a number of principles. My preferences are:
1) Any user customization should be in one place.
2) The impact on programs should be minimal (in LoC for example).
Both of those suggest the solution belongs in the terminal.
IMHO it starts with terminal programs having sane default colors. What that means is fuzzy, but so is this whole discussion. IMHO colors should follow the "standard" so that blue is still recognizably blue. But consideration should be given to the common forms of color blindness - for example I have a hard time reading pure red on black (adding a bit of anything helps this, don't just use ff0000).
Once terminals get fixed to have sane defaults, CLI programs should use those 16 standard colors. Any attempt to use 24bit here is either saying "I give up on getting those terminal folks to offer sanity" or it's saying something like "I know best", but either way users end up with N programs they have to configure. Lets not define themes in cli apps OK? Remember, this is my answer to "what would be the best way to handle this?"
I have similar thoughts when it comes to web sites and fonts. Present content in HTML so users can configure how they want to see it. Similar for page formatting - it's not a magazine layout, let it flow.
Also stuff in desktop software. IMHO Wayland compositors should remember window placement. It was stupid for every X program to store and restore its window position. Wayland says knowing about the environment is a security issue (and I agree) but then it becomes the DEs job to handle this memory. It also unburdens ALL the apps from having code for this.
There are other areas where that question comes up "Where in the software stack should this thing be handled?" Whatever your opinion, I believe you should start by answering the questions around that word "should". What are the goals in selecting where a thing gets handled? My answers always lean toward simplicity and maintainability. What other principles might I adopt to answer these questions?
[+] [-] weinzierl|1 year ago|reply
How difficult is this in practice? (Julia's article mentions this idea too without going deeper into the struggles)
A related topic is: Do terminal color schemes only concern themselves with the 16 base colors or do they also meddle with the RGB and greyscale parts. I mean you could also adapt the 8bit and 16bit colors to your readability requirements.
[+] [-] sim7c00|1 year ago|reply
Step 1: I think here maybe the default setting should be solarized-dark/light on terminals. It's honestly a good and sane default. It's purpose built to be less hostile on the eyes in my opinion, which should likely be what's aimed for in a default setting... the themes and colors are there for people who like to stare at their terminal all day (if you only use it once or twice then you don't care about what color it has) so it should be eye-friendly defaults. if people want to muck about changing it to their own custom theme they won't be bothered about defaults anyway since they will immediately customize it.
I personally hate the fact I even need to swap a theme, or download and reformat some Xresources file tediously (while looking at godawful colors in the process!). I just want my eyes not to burn.. don't care what colors yield that result.
[+] [-] Cthulhu_|1 year ago|reply
[+] [-] Narushia|1 year ago|reply
[+] [-] ykonstant|1 year ago|reply
[+] [-] mrweasel|1 year ago|reply
[0] https://no-color.org/
[+] [-] PaulHoule|1 year ago|reply
[+] [-] userbinator|1 year ago|reply
[+] [-] Yasuraka|1 year ago|reply
[+] [-] Sindisil|1 year ago|reply
Especially coding, I find almost all coloring to be distracting and counterproductive. Doubly so when I'm bouncing back and forth between Linux ans Windows. Many tools' default use of color borders on (or crashes head on into) unusable.
Some tools offer a --color=never option, and a good number respect NO_COLOR. Unfortunately, not all do, and even those that purport to assume that those modes will only be used for use in pipelines, programmatic interfaces, and such. That leads to all sorts of unfortunate behavior.
[+] [-] __s|1 year ago|reply
They have a consistent color scheme concept of semantically significant color temperature, while leaning warm to save your eyes from staring at so much blue light. Comes with alacritty colorscheme
[+] [-] chrsw|1 year ago|reply
[+] [-] noisy_boy|1 year ago|reply
[+] [-] dmd|1 year ago|reply
[+] [-] Narushia|1 year ago|reply
[+] [-] kps|1 year ago|reply
That also leads to problem 12: Certain popular terminals that default to setting TERM=xterm256-color while not being xterm-compatible.
Edit: I just came across `xtermcontrol`, which can abstract the background check in scripts, and is in all the major package managers.
[+] [-] setopt|1 year ago|reply
These days I just gave up and manually configure most apps to use ANSI colors (e.g. fzf etc have command switches for that), and let Vim and Emacs be the only non-ANSI apps which are instead set to match the colorscheme I use in the rest of the terminal. (Although stuff like vim-dim let’s you go one step further if you want.)
[+] [-] b112|1 year ago|reply
[+] [-] bad_user|1 year ago|reply
[+] [-] praptak|1 year ago|reply
When you're wondering why Emacs chose poor colors for something, it's often frame-background-mode being wrong.
[0]https://doc.endlessparentheses.com/Var/frame-background-mode...
[+] [-] Daneel_|1 year ago|reply
png file: https://drive.google.com/file/d/1mkMESeGf7MNdKa-rPDx7Yf9BDit...
imgur link: https://imgur.com/a/flatui-7mqVZAY
Based on: https://flatuicolors.com/palette/defo
[+] [-] lsllc|1 year ago|reply
However, Apple have languished with their Terminal support, they don't to >256 colors and some of the other more modern stuff is lacking and it doesn't really work with a Neovim+LazyVim setup.
I've been trying to find a "better" terminal and have bounced around between iTerm2, Kitty, Alacritty and Wezterm, but while they all are more "modern", I find that none of them seem to have that basic "New Window with Profile ..." option that lets me quickly open windows with different background colors/themes (at least without some screwing around).
Currently settled on Wezterm, mostly because it also works on Windows and I can share my wezterm.lua configuration (I should note that Windows Terminal is actually pretty good too). I still do find my self running Apple Terminal for quick things (e.g. using python3 as a REPL to do math or testing hex/binary stuff out etc).
[+] [-] p5a0u9l|1 year ago|reply
iTerm has exactly that.
[+] [-] larrik|1 year ago|reply
[+] [-] theshrike79|1 year ago|reply
There are a few things I miss from iTerm2 (mostly mouse related), but otherwise it took me a few evenings to configure it to my liking (cmd-n opens a new window at the default dir, not the current one) and I've been a happy user since.
[+] [-] vishnuharidas|1 year ago|reply
[+] [-] Arch-TK|1 year ago|reply
If you are writing a command line tool and you absolutely insist it must have colours then stick to the ANSI 16 colours or allow end users to customize the colour scheme.
[+] [-] theideaofcoffee|1 year ago|reply
Maybe because I've had to work on enough remote consoles without any, or limited, color support where I'm more concerned about the problem at hand than which shade of blue is being output for directories. Ok, I'll admit I adjust the default apple terminal 'pro' scheme colors a bit, adding a bit of contrast to the background because I'm in it all day, but beyond that, nothing. I find coloring has little to no positive effect on my productivity, and in some instances, hinders it. No colors on ls, I actually get a bit annoyed when color escapes reach stdout via logs now, hah. Hell, that extends even to my $PS1. I've never bothered to update it on this system. Crotchety, grizzled ops person perspective maybe?
[+] [-] powersnail|1 year ago|reply
[+] [-] oefrha|1 year ago|reply
That’s because Solarized only has 8 accent colors + 8 monotones: https://ethanschoonover.com/solarized/
Your 16 color all-color “Solarized Light” is a derivative work based on Solarized, not the original Solarized.
[+] [-] asdff|1 year ago|reply
[+] [-] sonar_un|1 year ago|reply
[+] [-] jeffbee|1 year ago|reply
[+] [-] esskay|1 year ago|reply
[+] [-] hibbelig|1 year ago|reply
I'm also not happy with Solarized because it's so low contrast.
Some programs have Github themes that seem to be okay.
I tried Catppuccin but I'm not sure if I like it or not. It's better than Solarized but still pretty low contrast.
Is there a color scheme I might like that's supported across multiple applications? IntelliJ, iTerm2, lazygit, neovim come to mind.
[+] [-] sevensor|1 year ago|reply
[+] [-] Arn_Thor|1 year ago|reply