[HN Gopher] Terminal colours are tricky
___________________________________________________________________
Terminal colours are tricky
Author : chmaynard
Score : 331 points
Date : 2024-10-03 06:58 UTC (1 days ago)
(HTM) web link (jvns.ca)
(TXT) w3m dump (jvns.ca)
| ykonstant wrote:
| 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
| weinzierl wrote:
| Would you share how you configured your fbterm?
| ykonstant wrote:
| Here is a pastebin of my config, adapted from Lu Xu's
| dotfiles [0]
|
| https://pastebin.com/RgbgLUTq
|
| [0] https://github.com/xlucn/dotfiles
|
| It is Lu Xu's dotfiles you should focus on if you want to
| understand how fb* tools work.
|
| I invoke fbterm via this script to set the bg image:
| #!/bin/sh # fbterm-bi: a wrapper script to enable
| background image with fbterm # usage: fbterm-bi
| /path/to/image fbterm-options printf '\033[?25l'
| # hide cursor fbv -ciuker "$1" << EOF q EOF
| shift export FBTERM_BACKGROUND_IMAGE=1 exec
| /bin/fbterm "$@"
| weinzierl wrote:
| Oh nice, I will give it a try. Thank you so much!
| HPsquared wrote:
| 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.
| phkahler wrote:
| That sounds reasonable. But sometimes I have a bunch of
| signals with some of them being pairs, so having a dark and
| light version of the same color helps to see them together.
| Does this work with adjacent rainbow colors as well?
| HPsquared wrote:
| You can use the same hue with different luminance.
| jve wrote:
| All those nice fonts and pleasant color theme... ruined by a
| background that makes some characters hard to read :)
| ykonstant wrote:
| Oh, you mean the picture I linked? That's just to look cool
| on a screenshot, obviously you won't work with a background
| picture getting in the way! :D
| wolfspaw wrote:
| Nah, the background picture is based xD
| sricciardi wrote:
| > 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.
| klodolph wrote:
| This is why, as policy, I don't judge negatives any more. I
| always print contact sheets and make my initial judgments
| there.
| Macha wrote:
| > 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
| wolfspaw wrote:
| Your stylized fbterm screen is awesome, always good to have a
| cute anime girl lol.
|
| Really good colors and organization of the terminals, it would
| be great for serious work too in my view =p
| mschuster91 wrote:
| > 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.
|
| [1] https://www.gnu.org/software/gettext/manual/html_node/The-
| TE...
| lathiat wrote:
| Was going to say "hey just set $TERM", then saw your comment
| and actually read the article which covers all of this pretty
| well. But, not only am I annoyed about this, but I feel that
| being annoyed about this confirms I am definitely getting
| old. _yells at cloud_
|
| Starting using Linux at 15 in 2002. Didn't realise how
| "early" that was then (especially compared to now, seemed old
| then). Been working professionally in the space since 2006.
| Now I'm 37. Yikes.
|
| On the plus side it definitely works for your more basic
| tools.. for most of the non-basic ones, as a hack you could
| pipe the output to "cat" as most tools try to detect if the
| terminal is interactive or not to remove colors from output
| being piped. It also annoys me we don't have a better way to
| signal that, and I have to pass --colors and hope it's
| supported to every command where I want the colors but just
| to filter the output by line with grep.
|
| Anyway...
| rcarmo wrote:
| As someone who spent an hour yesterday trying to color match
| WezTerm and Apple Terminal to run vim legibly, this came in very
| handy,
| Cthulhu_ wrote:
| 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.
| ykonstant wrote:
| Oh, that is fascinating.
| possibleworlds wrote:
| The creator has a huge amount of docs surrounding the project
| that are quirky and very informative https://linktr.ee/Myndex
| Narushia wrote:
| 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.
| weinzierl wrote:
| _The answer seems to be "there's no standard, terminal emulators
| just choose colours and it's not very consistent"._
|
| The colors themselves are one part of the equation, the other
| being the mapping to semantic elements, like GUI widgets or
| syntax groups.
|
| I feel there are some unwritten rules despite and beneath all the
| apparent inconsistency.
|
| For example keywords are almost universally somewhere in the red
| blue area, never green. For comments it's the opposite, most
| often greenish or grey.
|
| But this is all tacit and to the best if knowledge nowhere
| written down.
| chrismorgan wrote:
| > _For example keywords are almost universally somewhere in the
| red blue area, never green._
|
| This isn't true. Blue's probably most common these days, but
| black, orange, brown, yellow, green... they're all pretty
| common, probably similarly common to red. In Pygments, the
| default theme even uses bold green for keywords.
|
| > _For comments it 's the opposite, most often greenish or
| grey._
|
| OK, this one's more true. Other colours are sometimes used, but
| greens and greys are far and away the most common.
| o11c wrote:
| > The answer seems to be "there's no standard, terminal
| emulators just choose colours and it's not very consistent".
|
| It does seem like half this article is correctly answered by
| "there is a standard (VGA), but some terminals (and in
| particular, the Solarized colorschemes) trample all over it and
| break _everything_. "
|
| Like, there are indeed a lot of buggy terminals, but Solarized
| will ONLY ever make things worse, since _all_ correct programs
| assume something close to VGA.
| hnlmorg wrote:
| I actually don't think it's that hard:
|
| 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.
| weinzierl wrote:
| _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.
| hnlmorg wrote:
| There is no 16bit. You cannot alter the 24bit (at least not
| on your average terminal emulator).
|
| Same is true for 8bit. Most terminal emulators tend not to
| support altering those colours either.
|
| In practice, the only application I use that I've had to
| configure the colours for was tmux. But I tend to forget
| about tmux because its one of those applications that needs a
| lot of a configuration from the outset anyway (in my opinion
| at least).
|
| There might be other "must have" tools that set the
| background colours too. I've either not needed them
| personally, or have completely forgotten about them
| arp242 wrote:
| > 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.
| prmoustache wrote:
| I don't know what pamix is but my rule of thumb is to use
| only apps that supports themes that are common in most
| terminals, text/code editor like solarized, gruvbox...
| sim7c00 wrote:
| 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.
| hnlmorg wrote:
| I completely agree. And for what it's worth, I set Solarized
| dark as the default theme on the terminal emulator I've
| written. Though it's not quite ready to be used as anyone's
| primary TERM just yet.
| tmtvl wrote:
| I would disagree that solarized is a good default, the colour
| it uses for blue (which is used by ` _ls_ ' to show
| directories) is so low contrast it wears my eyes out.
| kibwen wrote:
| Seconded. By all means, people should use what they
| personally like, but solarized is really not designed to be
| a terminal mapping. Half the brights get mapped to totally
| different hues and the other half get mapped to
| indistinguishable shades of gray. Yes, the standard
| terminal color values are hideous, but we can do better
| than solarized.
| hnlmorg wrote:
| What would you recommend?
|
| Same questions to others who've posted qualms with
| Solarized.
|
| I tend not to spend much time configuring things these
| days so have always landed on Solarized out of laziness.
| kibwen wrote:
| To reiterate, I'm not here to say anyone is wrong for
| using solarized, only that as a terminal default it would
| eliminate the ability of terminal applications to assume
| that bright green, bright blue, bright cyan, and bright
| yellow are anything other than shades of gray. If that's
| fine for your use case, then no harm. And plenty of
| people tweak solarized to make these colors usable and
| distinguishable, but of course this obviates the whole
| light mode/dark mode party trick that is solarized's
| raison d'etre.
|
| There are lots of websites out there where people have
| shared their terminal color schemes, I would recommend
| seeking one out and looking for a screenshot of one that
| catches your eye.
| hnlmorg wrote:
| Don't worry, I wasn't taking your comment as personal
| critique. :)
|
| And to be fair to Solarized, it was really novel when it
| came out. But we've had years to improve upon it since.
|
| So I'm genuinely interested to hear some recommendations.
| Ideally themes that are "standardised" (for lack of a
| better phrase) so that I'm likely to find a VSCode theme
| as well as iTerm2 etc.
|
| I know I could just look online myself but customisation
| can quickly end up becoming an "addiction" (again, for
| want a better phrase) where you spend more time
| "configuring" than "doing". A procrastination trap I've
| fallen into many times before. The appeal of Solarized is
| its better than most defaults and it's easy to find so
| that stops me from spending too much time playing. And
| the appeal of having someone else tell me to use
| something else is that I also don't fall into that
| proverbial rabbit hole.
| kibwen wrote:
| Totally fair. In truth, modern terminal emulators have
| come a long way since the days of opening up CMD.exe or
| Putty and cringing at their peaked RGB sliders. Nowadays
| when I install a new terminal it tends to come with a
| decent color scheme out of the box. But if you insist, I
| could extract the color scheme that I made for myself a
| decade ago, though I decline to give it its own name or
| website. :P
| ziml77 wrote:
| For some reason that blue is a problem in a lot of color
| schemes. It's a good test for me though. If I can't read
| the output of ls, I dump the color scheme.
| layer8 wrote:
| Solarized it too low-contrast for my eyes. For some people
| low-contrast means easy on the eyes, for others it is the
| opposite.
| bhaak wrote:
| > 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.
| hnlmorg wrote:
| > 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.
|
| Agreed to an extent. I wouldn't call ignoring the systems
| colour preferences as "good defaults". But I do agree with
| your more general point.
|
| > 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.
|
| Unfortunately it's not that simple. Both the "256color"
| suffix to $TERM and $COLORTERM env vars report terminal
| compatibility -- not user preference.
|
| Neither are standards either. It's a push to even call them a
| _de facto_ standard because they 're often not used by either
| terminal emulators nor application developer alike.
|
| There is another env var that does report user preferences:
| $COLORFGBG, but that receives even less support than the
| former two vars.
|
| There's also $NO_COLOR (or is $NOCOLOR?), which seems to be
| honored a little better. However the problem with this is it
| turns colour off completely. ie you cannot specify "use 4bit
| but not 8bit nor 24bit colour".
|
| Like all things terminal detection wise, it's all a big fat
| steaming mess of inconsistencies. Which is why I think the
| best default is 3/4bit or no colour at all if $NO_COLOR / not
| a TTY. And have all the cool 24bit themes as an optional
| extra.
| NoGravitas wrote:
| It's also the case that a lot of modern CLI tools will
| absolutely ignore your termcap and your $TERM env var and
| barf out whatever extension to ANSI is used by the
| currently most popular terminal emulators.
|
| Unless it's a TUI app that I'm going to spend a lot of time
| in (e.g., Emacs), I do not want it theming itself. I want
| it to look at my termcap to see if it has ANSI color
| support, and if it does, then emit ANSI color codes. I use
| base16-shell to set my terminal colors and I want CLI and
| TUI apps to respect them.
| bhaak wrote:
| > Unfortunately it's not that simple. Both the "256color"
| suffix to $TERM and $COLORTERM env vars report terminal
| compatibility -- not user preference.
|
| Terminal compatibility that is expected to be used. If you
| only want the 16 base colors then this is the way to go.
| This is the most reliable and best supported way to get
| that in the terminal.
|
| If you want some tools to still output 256 colors, you can
| change the TERM variable on the fly: "TERM=$TERM-256color
| infocmp -L".
|
| You also should unset COLORTERM. It's for specifying that
| this terminal supports 24bit colors.
| phkahler wrote:
| >> Step 2:
|
| >> 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?
| kevin_thibedeau wrote:
| > What would be the best way to handle this?
|
| A styling service from systemd.
| fwip wrote:
| 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.
| Arch-TK wrote:
| 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.
| powersnail wrote:
| 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.
| chrismorgan wrote:
| If you're a CLI, you should _never_ (a) set background colours,
| or (b) use more than the 16 colours range1, unless the user
| configures it so.
|
| If you're a TUI (as in, full-screen terminal app), you should
| _probably not_ (a) set background colours, or (b) use more than
| the 16 colours range1, unless the user configures it so.
|
| --***--
|
| 1 And you can't even wisely use most of the 16 colour range--
| the intense colours might be higher _or lower_ contrast, so
| they're not useful how people want to use them, and black and
| white could both be either the higher contrast or literally
| invisible, when used against the default background; and blue,
| yellow, bright yellow, bright cyan are each very difficult to
| see on some common themes, those that's becoming less common.
| powersnail wrote:
| Sadly, the state of CLI and TUI tools is that background
| colors _will_ be encountered soon or later, if you use a wide
| range of software. And I struggle quite a bit sometimes to
| make everything in my terminal legible.
| samatman wrote:
| I'm genuinely unsure what you mean here. In SGR, 30-37 are
| foreground colors, 40-47 are background, and the brights are
| 90-97 for foreground and 100-107 for background. Even the
| second bright set is quite old, xterm calls them the aixcolor
| because they originated in IBM's AIX in the 1980s. I've never
| seen terminal software which doesn't support these and
| definitely never encountered one where the difference between
| foreground and background was negotiable. The concept of a
| color independent of being foreground and background can't be
| expressed in SGR codes.
| Narushia wrote:
| 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. :)
| bbarnett wrote:
| Many terminals (konsole from trinity/tde3) allow you to
| customize the colour of the primary colours, which helps.
| bad_user wrote:
| I'm not having issues with macOS's iTerm, and the programs that
| I use, like neovim, looked good out of the box.
| setopt wrote:
| 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.)
| kps wrote:
| 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.
| samatman wrote:
| It doesn't have to be cataracts, my eyes are just unusually
| sensitive to light. I find the hacker news theme borderline
| during the daytime, and can only handle it for short bursts
| at night with the brightness on my monitor set to the lowest
| setting.
|
| It's probably too late for terminals to add a concept of
| semantic color, other than "default foreground" and "default
| background", but the situation as it is forces TUI authors to
| either stick to the basic eight or make colors completely
| user-configurable, if they don't want to leave anybody out.
|
| By semantic color I mean what editors do, where the
| presentation is separated from the intention. Unclear how to
| even start with that for terminals though.
|
| (To someone out there about to tell me about how I can custom
| theme HN: please consider that I might spend too much time
| here already and don't need it to be easy to use in the dark.
| Cheers)
| vanous wrote:
| Glad to see someone else to use solarized light in terminal. I
| have this in terminal, vim, mc... custom tweaked and I love it.
| Arn_Thor wrote:
| There is something deeply fondly nostalgic about looking at that
| ANSI color table
| praptak wrote:
| Emacs has its not super discoverable frame-background mode[0]
| which is effectively either 'light' or 'dark'.
|
| 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...
| teddyh wrote:
| Better link: <https://www.gnu.org/software/emacs/manual/html_no
| de/emacs/Fa...>
| o11c wrote:
| Often the underlying problem is a failure of the terminal to
| set the `COLORFGBG` variable.
|
| For dark-background terminals with white text:
| export COLORFGBG='15;0'
|
| For light-background terminals with black text:
| export COLORFGBG='0;15'
| vishnuharidas wrote:
| 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.
| oefrha wrote:
| > I'm not sure why the iTerm Solarized theme is designed this way
| (there must be a reason!)
|
| 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.
| Daneel_ wrote:
| 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:
|
| 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
| bloopernova wrote:
| Looks similar to the One Dark theme which was originally from
| the Atom editor iirc.
|
| I've been using mine for about a decade too. It works well for
| iTerm, vim, Emacs, vscode etc etc
| prmoustache wrote:
| Problem 8: I am not really an mc user but I don't find the
| screenshot with the solarized theme disorienting at all.
|
| Everything is legible. You need to be the pickiest picky princess
| of pea to be annoyed by that.
| tmtvl wrote:
| I've got my terminal set up to use a colour scheme based on
| Prot's Modus Operandi (https://protesilaos.com/emacs/modus-
| themes) theme for Emacs. I can read the output of ` _dmesg_ ' and
| ` _ls /_' without problems, so it's good enough for me.
| mrweasel wrote:
| Emacs users always write the longest, most detailed
| documentation.
| NoGravitas wrote:
| Do you have someplace you can share this? I'd love a pair of
| 16-color terminal color schemes based on Modus Operandi and
| Modus Vivendi.
| tmtvl wrote:
| The ones I'm using I have 'adapted' for QTerminal from these
| Konsole themes: https://www.opencode.net/sterric/konsole-
| modus-themes
|
| And by 'adapted' I mean I just removed the Anchor, Blur,
| ColorRandomization, FillStyle, WallpaperFlipType, and
| WallpaperOpacity attributes. I don't know whether I could've
| just left them be, but they don't really matter anyway.
| mrweasel wrote:
| 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.
|
| [0] https://no-color.org/
| dmd wrote:
| These are presumably the same people 'raw dogging' trans-
| oceanic flights.
| chrsw wrote:
| I'd rather see this than colorful anime backgrounds and emojis
| in shell prompts.
| theideaofcoffee wrote:
| Same. There are few things that annoy me more when working in
| the shell than unexpected emojis in outputs to be cute or
| more accessible or whatever. I'll take the occasional
| readline and curses shenanigans but even then there's usually
| a way to disable those to have pure character outputs and no
| control chars.
| Yasuraka wrote:
| 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.
| lelandfe wrote:
| Sounds like those pieces of software should also work on
| being more resilient to color sequences.
| PaulHoule wrote:
| :syntax off
|
| 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_.
| Sindisil wrote:
| Me, for one.
|
| 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.
| noisy_boy wrote:
| 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.
| userbinator wrote:
| 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.
| kps wrote:
| I take the Incredibles approach: When everything is coloured,
| nothing is.
| __s wrote:
| I'm moving in that direction. See zenbones. I ended up with
| https://github.com/savq/melange-nvim
|
| 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
| k3vinw wrote:
| I use base16 shell across my terminal emulators and at least in
| gnome or xfce terminal I found that it helps to reverse white
| text on black backround when using a light theme. And flipping it
| back when using a dark theme. Makes me wish they had that auto
| contrast feature.
| myworkinisgood wrote:
| I'm pretty happy with my colors
|
| 1. https://imgur.com/qCTB8bx
|
| 2. https://i.imgur.com/kr3AOoX.png
| theshrike79 wrote:
| The bright green on white is somehow hard to read for me
| Max-q wrote:
| "bright yellow on white" and "dark blue on black": I thought the
| system was designed so that you should use a bright colors on a
| dark color or opposite, not two colors in the same group?
| PaulHoule wrote:
| The #1 problem w/ the above article is that "color" doesn't
| matter but brightness and value do.
| o11c wrote:
| If that ever happens with a properly implemented terminal, it's
| an application bug. But buggy terminals are _very_ common.
|
| Sometimes it's due to COLORFGBG not being set.
|
| Sometimes it's due to failing to implement the legacy "bold =
| intense" hack (from the 8-color days), which very many programs
| rely on.
|
| Sometimes it's due to the colorscheme having all colors be too
| bright. It's abominable how far some of those colorschemes are
| from the VGA standard.
|
| (Sometimes it's a gamma-ish problem. I can't believe it's
| $CURRENTYEAR and computer screens still vary so badly).
|
| ---
|
| Here's a quick test for several problems. These are bad color
| combinations that shouldn't be _chosen_ , but they should be
| readable with just a bit of effort. Output is 2 lines, one
| offblack-on-black, one white-on-offwhite.
| printf '\e[3%d;1;4%dmThis should be (barely) readable.\e[m\n' 0
| 0 7 7
|
| Results with default configuration on Debian stable:
| alacritty: fail (no obvious configuration) cool-retro-
| term: pass (despite deliberately neutering color) deepin-
| terminal: marginal pass (colorscheme too bright) Eterm:
| pass foot: fail (no obvious configuration; buggily
| packaged as X11 despite being Wayland-only) gnome-console
| (really?) = kgx: fail (configuration does not contain an
| obvious fix) gnome-terminal: fail (need to go into
| preferences and check "show bold text in bright colors")
| kitty: fail (no obvious configuration) konsole: half-fail
| (colorscheme too bright) linux: pass lxterminal:
| fail (check "bold is bright" in preferences) mate-
| terminal: pass mlterm: pass pangoterm: pass
| pterm: pass qterminal: pass rxvt: pass (it, along
| with its derivatives (I don't remember which right now, but
| several are probably listed here), has other unfixable bugs
| though, and should be avoided unless you are deliberately
| trying to write a program that works even with abominable
| terminals) sakura: fail (no obvious configuration)
| stterm: marginal pass (colorscheme too bright) terminator
| (the gnome one): fail terminology: pass termit:
| fail (configuration does not contain an obvious fix)
| tilix: pass xfce4-terminal: pass xiterm+thai:
| marginal fail (colorscheme contrast too low in both directions
| somehow) xterm: pass yakuake: half-fail (as
| konsole) zutty: marginal pass (colorscheme too bright)
|
| (not that this test is _only_ for colors, not for the many
| other features you might expect a terminal to support)
| HenryBemis wrote:
| No they are not. I've played MUDs enough years on my life to know
| that the best is black background, bright green letters. Prompt
| with white. Exits/entries with Yellow. Chats with light
| blue/aqua.
| lsllc wrote:
| 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).
| graemep wrote:
| Konsole (the KDE terminal) does this (either from the manu or
| click and hold on the new tab icon) and I believe it is
| available for MacOS.
| larrik wrote:
| That's weird, as I dumped Apple's terminal very quickly in
| favor of iTerm2 specifically because it support "new tab with
| profile".
| p5a0u9l wrote:
| > none of them seem to have that basic "New Window with Profile
| ..."
|
| iTerm has exactly that.
| jamesgeck0 wrote:
| If you want to add "New Window with Profile..." to WezTerm, you
| can probably hack something into either `launch_menu` [1] (for
| starting different shells), or `augment-command-palette` [2]
| (for adding items to the command palette).
|
| 1.
| https://wezfurlong.org/wezterm/config/lua/config/launch_menu...
|
| 2. https://wezfurlong.org/wezterm/config/lua/window-
| events/augm...
|
| Yeah, it takes some screwing around, but programming extremely
| specific features just the way you want them is peak WezTerm
| experience.
| theshrike79 wrote:
| 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.
| sonar_un wrote:
| 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)
| sam0x17 wrote:
| For me I've always gravitated to what is essentially the "One
| Dark Pro" theme originally from Atom that has been ported over to
| VSCode and other things, and is almost identical (in terms of
| terminal colors anyway) to the default theme installed by
| OhMyZsh. So these days I just default install OhMyZsh and I'm
| good to go.
| sevensor wrote:
| Minimum contrast! What a great feature! One of which I was
| entirely unaware until just now.
| theideaofcoffee wrote:
| 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?
| buggy6257 wrote:
| For me it's about utility. I don't buy any arguments saying
| don't use aliases or colors because others won't have them. 90%
| of my terminal interaction is on my terminal so I'm not too
| bothered.
|
| It takes me maybe 10min when I get a new computer (usually Mac)
| to have Oh My Zsh and Powerlevel10k installed on my machine,
| configure p10k with the awesome setup wizard, change to my
| coding font, and tweak my background and foreground to dark
| teal/off-white. After that I never have to touch it again and
| it looks amazing for the rest of my working days. The default
| PS1 mods from p10k giving me directory context, info on k8s,
| docker, and python venv, along with info on last run cmd like
| exit code and runtime, are all just so valuable and I got them
| for basically free.
|
| I can understand not wanting to constantly tweak it and I agree
| with that but I would have to disagree that making any
| customization is a waste of time.
| JohnFen wrote:
| I don't bother about the colors because white on black is
| excellent for me and I prefer not to have the output colorized.
| Makes things easy. :)
|
| I lie a little... I do disable colorization when possible, or
| set everything to be white on black when I can't just turn it
| off.
| Sindisil wrote:
| Pretty much same, but over time I've switched to dark on
| light in terminal. Easier for me to read these days. Still
| use "night mode" often on my phone, mostly to save battery
| (OLED).
| UI_at_80x24 wrote:
| I agree and disagree with you. Same 'grumpy old sysop' energy.
| Same as you I, ssh into 100 different servers on dozens of
| client networks. Too many have a stupid amount of restrictions
| in the name of security that prevent changes or enforce
| settings. i.e. One client has a 'forced' PS1 output that shows:
| RAM free/total HD space free/total CPU load TOP cpu item
| Previous command
|
| All with obnoxious colours AND blinking if a threshold gets
| met. .bashrc (and associated)is read-only (and) overwritten at
| every login.
|
| But, I can `source .my-env` And bring sanity to my session.
|
| I'd rather have a 'default-plain' then some forced-bling that a
| dev thought was cool 20 years ago.
| rconti wrote:
| This is how I feel about virtually all "personalize your
| environment" discussions. The sheer level of effort to ship
| preferred shells and tools and aliases and dotfiles and color
| schemes around the thousands of nodes I touch in a given year
| makes it all feel like a losing bet. It means every little
| change feels like a new insurmountable chore I just placed on
| myself.
|
| Now, yeah, in the case of the terminal, it's probably not so
| bad because the remote system _probably_ won't override my
| settings, or it's probably relatively easy to force my side to
| take priority, but it still falls into the bucket of "huge
| chores with minimal payoff".
|
| Also crotchety, grizzled ops person who invests too much time
| into solving the problem right in front of them and not enough
| time into stepping back and engaging in possibly-fruitful
| sidequests.
| jeffbee wrote:
| Solarized has the core of a good idea but a lot of problems in
| the details. I started from Selenized. https://github.com/jan-
| warchol/selenized/blob/master/whats-w...
| esskay wrote:
| 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.
| zokier wrote:
| People in this thread complain about 8/24 bit colors, but how
| difficult would it be to have terminal emulator simply map 8/24
| bit colors to the 16 ANSI color palette? Shouldn't that resolve
| most of the concerns?
| o11c wrote:
| The 16-color palette is pretty limited so even for text that
| would be readable with full color, you can end up with either
| invisible text (black on black, for example) or really ugly and
| glaring (red on blue).
|
| Mapping from 24-bit color to the 256 color cube is pretty
| reasonable though, since the colors are close enough that you
| would have a hard time reading them in the first place.
| tempodox wrote:
| Definitely one of the deeper rabbit holes to let yourself fall
| into when you feel like procrastinating. I'm content if both
| syntax coloring in vim and file type coloring in the shell are
| readable. I've got more interesting things to do.
| layer8 wrote:
| The approach I find most practical is:
|
| - Only use the 16 ANSI colors, with the default (or user-
| configurable) background.
|
| - Configure the 16 colors on your terminal client so that they
| are readable on your chosen background color(s).
| SoftTalker wrote:
| Yep. I used to waste _so_ much time on tweaking colors and
| themes. I just go with the defaults now. I don 't always like
| them, but screwing around with colors and fonts is just an
| endless no-win battle. No matter what you come up with you'll
| run into an app that does something nonstandard and then your
| carefully constructed theme looks like crap.
| nubinetwork wrote:
| I learned this a few years back when switching back to KDE after
| being a MATE user... for some reason KDE insists on using a
| different palette, so it breaks some apps that use colours...
| notorandit wrote:
| Really?
|
| I still think that white on black and green on black still work
| very well. At least for me in the past 40 years.
| drewg123 wrote:
| I just disable colors wherever I can. And curse the UEFI shell
| and its dark-blue-on-black whenever I'm forced to use it..
| kelvie wrote:
| Looks like Konsole doesn't support this (just switched from Kitty
| on KDE, because on wayland, Qt apps survive a compositor
| restart!), but there has been a request since 2022:
|
| https://bugs.kde.org/show_bug.cgi?id=451109
|
| I wonder how hard this is to patch.
| diath wrote:
| > because on wayland, Qt apps survive a compositor restart!
|
| Realistically, how often do you restart your compositor and
| why?
| hibbelig wrote:
| I wanted to like dark mode (before it was called that, back in
| the nineties), and I try again from time to time, but I've never
| been successful.
|
| 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.
| tracker1 wrote:
| I used to match my terminal theme to CGA colors (DOS ANSI), the
| lighter colors on VGA default aren't quite the same (wikipedia
| screenshot). You can get the right color codes from something
| like Pablo or Moebius. It's a bit of a pain, and I'm honestly
| surprised more terminals/editors don't have a "DOS ANSI" theme
| option that matches those color codes. I have a reg file saved to
| do it for the old Windows console, but dropped windows a few
| years ago, and even then was using the new terminal.
| anthk wrote:
| Tango color scheme. Perfect for everything.
| loeg wrote:
| The base16 shell script thing is new to me, that's really neat if
| it works.
| asdff wrote:
| 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.
| 3np wrote:
| > problem 9: commands disabling colours when writing to a pipe
|
| An alternative to the suggested unbuffer trick is to tell your
| receiving programs to handle color by default (case-by-case or in
| .profile) LESS=-R less
|
| > LS_COLORS
|
| man dircolors(1) has more info
| joveian wrote:
| This isn't an alternative since most programs won't send the
| color by default to a pipe (however, it is much better to use
| less -R than the article's -r so you don't get other escape
| codes causing trouble). The alternative to unbuffer is that
| most commands that use color (in my experience) recognize
| --color=always (or --color=never or the usual default
| --color=auto for no color to pipes).
| eddyg wrote:
| echo SYSTEMD_COLORS=16 | sudo tee -a /etc/environment
| willy_k wrote:
| An aside, but I love the Serendipity V1 (the new version not so
| much) VSCode theme, wondering if anyone else has used it?
| aragilar wrote:
| My personal rant is terminals where you cannot configure the
| default `TERM`.
| geon wrote:
| I hate how the macos terminal "helpfully" adjusts colors. That
| just means I can't get my custom theme to look right.
___________________________________________________________________
(page generated 2024-10-04 23:01 UTC)