5 ms·

Design, edit and share custom terminal color schemes

92 points by rohan1024 6y ago

hnlmorg 6y ago
A note to any developers writing console applications, please please please don't use RGB values in your terminal colour -- only use the 8 base colours plus highlight. RGB values prevent your users terminal from using the custom colour palettes your users might define (and like this site helps you to create). Aside from being a little annoying, it can cause genuine usability problems for some groups of people who use custom palettes: - for visual impairment reasons (eg high contrast colours) - or to differentiate different servers (eg different background colours for dev or prod servers) - or have less contrasting colours to reduce eye strain (eg the Solarized colour schemes) - might suffer from colour blindness so pick colours that contrast better with their condition - or even just those that prefer a white or other non-black backgrounds for readability reasons (eg they might be dyslexic and find a non-black background or different shades of text easier to read). I do fall into two of those categories and run into this issue a lot since there is a trend these days for developers to hard code colour values into their applications. Equally, some developers use the "you can select a custom colour map - I just define a pretty default" argument and while that's slightly better, the best option would be still to default to the standard 8 colours (or the default unformatted text) and let users opt into RGB values if they wish. This will save your users from constantly having to define the same colour palettes in every application.
- DarkWiiPlayer 6y ago
  Default to standard terminal colours and allow customization if necessary (I think vim handles colours very nicely :D)
  - hnlmorg 6y ago
    > Default to standard terminal colours That's my point :)
- JdeBP 6y ago
  As I noted at https://news.ycombinator.com/item?id=22002036 https://news.ycombinator.com/item?id=22002036 . (-: It has been really 16 colours since the days of AIXTerm, even though that did not get formally standardized. Only a couple of places nowadays make the error of conflating bold and bright. It's not really "8 base colours plus highlight" at all, and that's certainly not the case with the tool at hand. You are also approaching being a decade late with a plea not to use direct RGB colour. https://gist.github.com/XVilka/8346728 https://gist.github.com/XVilka/8346728 started in 2014, for example. What the tool at hand really tells us is that there are already at least 18 different ways of specifying a colour palette. Perhaps the better idea nowadays is to promote a common 16-colour-to-RGB palette mechanism for TUI applications, akin to mailcap or something.
  - a1369209993 6y ago
    We have a common 16-color-to-RGB mechanism: write \e[34m or similar and let the terminal do its damn job.
    - JdeBP 6y ago
      No, you do not have that. For starters, it's still a matter of debate whether the world is wholly ECMA-48:1976 yet. There are people who contend that we cannot assume universal adherence to a 1976 standard. * https://unix.stackexchange.com/q/548158/5132 https://unix.stackexchange.com/q/548158/5132 * https://unix.stackexchange.com/a/5802/5132 https://unix.stackexchange.com/a/5802/5132 Then there's the matter that only colours 0 to 7 are in fact standardized in ECMA-48. That's 8 colours, not 16. The AIXTerm mechanism has never been standardized, and what has been standardized in the likes of ITU T.416 is both not the AIXTerm mechanism and badly implemented to the extent that people are still today pushing for two long-standing mistakes to be corrected by software authors. Moreover, not every terminal agrees on how to interpret even the non-T.416 SGR control sequences. Famous and still widely used terminal emulators, such as the Linux built-in one for its KVTs, respond to boldface (SGR 1) by changing colour; in contrast to many terminal emulators where boldface means boldface and isn't a colour change. The control sequences are not the same and cannot be hardwired. * https://unix.stackexchange.com/a/608930/5132 https://unix.stackexchange.com/a/608930/5132 Personally, I am of the opinion that one can nowadays assume ECMA-48:1976 at minimum as long as one allows for "dumb" as well. But that doesn't mean further assuming the AIXTerm 16-colour mechanism. Until you go and change the Linux KVT's (and others') handling of boldface, and then the "linux-16color" entries in termcap and terminfo, to actually match your claim, your claim will remain incorrect. (Also note the caveats at https://news.ycombinator.com/item?id=23752827 https://news.ycombinator.com/item?id=23752827 .) Then there's the fact that a decent common TUI palette system wouldn't be 16-colour-to-RGB, because that would still need a second map. It would be better than that. That's just a barebones concept. It would be display-element-to-RGB, learning from the design of GUI palettes back in the 1980s, where the colour schemes specified colours for abstract UI elements such as "window title", "pressed button", "file", "directory", "text label", and the like. And indeed from the design of Borland TurboVision, which did the same.
- a1369209993 6y ago
  > only use the 8 base colours plus highlight. Those are actually called "RGBI"[0] colors (which would make the 8 base colours "RGB", though I haven't seen that usage), although that's clearly not what you mean by "RGB values". 0: 1 bit each for red,green,blue,intensity: #(r·AA+i·55,g·AA+i·55,b·AA+i·55)
  - hnlmorg 6y ago
    No, the colours I'm talking about aren't defined as RGBI values. Wikipedia has good introduction to the different SGR colour parameters: https://en.wikipedia.org/wiki/ANSI_escape_code#Colors https://en.wikipedia.org/wiki/ANSI_escape_code#Colors I'm talking about 3/4-bit (8/16 colours) not 8-bit (256 colours) nor 24-bit ("true colour"). The 3/4-bit colour palette is configurable in most terminals. True colour is not.
    - a1369209993 6y ago
      I'm talking about the 4-bit (RGBI) ANSI color palette, used by \e[34;44;94;104m escapes. 8-bit or 24-bit color should not be supported by terminals in the first place (and certainly shouldn't be used by terminal applications), for the reasons you mentioned above.
      - da39a3ee 6y ago
        I think both of you are talking about the same thing. Please don't assume that your views are generally held or will meet with general approval. I think what you're saying is completely wrong and wildly inappropriate. In general, there will exist many terminal applications where the designers should feel absolutely free to use 256 and full-RGB colors if they wish to, seeing as the technology has supported it for years. An example is color themes for syntax highlighting; the designers of color themes obviously _can_ restrict themselves to 16-color palettes (e.g. https://github.com/chriskempson/base16 https://github.com/chriskempson/base16) but they are perfectly free not to. I do not understand what makes you think you have the right to demand that people impose such a vast restriction on terminal applications. The web supports 256 colors and full RGB; why shouldn't terminal applications?
- lokedhs 6y ago
  In addition to what you are saying, I'd also ask developers to not use escape sequences directly but instead use terminfo. It allows you to send the correct terminal sequences regardless of the type of terminal you use. In particular, it allows your users to completely disable the highlights by using TERM=dumb. Also, please check if the output is a tty (the isatty libc call) I don't know how many applications with fancy coloured output that looks completely broken when redirecting to a file.
- da39a3ee 6y ago
  > please please please don't use RGB values in your terminal colour Can you clarify what your suggestion is please? I assume you're talking about ANSI color escape sequences. There are 3 different ways colors are represented using ANSI color escape sequences (see https://en.wikipedia.org/wiki/ANSI_escape_code#Colors https://en.wikipedia.org/wiki/ANSI_escape_code#Colors) 1. Using the 16-color palette which is dynamic and under user control. 2. Using the 256-color palette, which are hardcoded colors. 3. Specifying 24-bit colors (RGB), which also hard-coded colors. Are you asking developers of terminal applications to use neither (2) nor (3)? If so, that seems like an extraordinary, and inappropriate, request. I do hope however that developers of terminal applications make it possible to configure the application to use (1). For example, do you disapprove of the existence of all syntax highlighting color themes unless they use only the base 16 colors?
  - 0xffff2 6y ago
    Not OP, and not constrained by any accessibility needs, but restricting your terminal applications to (1) sounds entirely reasonable to me. At the very least, (2) and (3) should be entirely opt-in, never defaults.
    - kergonath 6y ago
      Or specific uses (someone else thread mentioned image rendering; I really like the sixel terminal in gnuplot to eyeball stuff from a server without bothering with X; there are plenty other uses for high-resolution full rgb graphics in a terminal).
    - da39a3ee 6y ago
      What about syntax-highlighting color themes? Although a subset of color themes (e.g. base16) are specifically designed to use the dynamic 16-color palette, my understanding is that it's routine in the color-theme world to allow yourself to hardcode colors from the 256-color palette. So an application making use of syntax-highlighting color themes would certainly make 256 color support default, wouldn't it?
      - 6y ago
jaquers 6y ago
Really well done application with tons of export / import formats, lots of presets and the palette is integrated into the UI - delightful. Thanks for the submission.
- kergonath 6y ago
  Indeed. And a great use of the .sexy TLD.
  - cptnapalm 6y ago
    Sadly, it triggers my work's block filter.
shiftpgdn 6y ago
Vaguely off topic but has anyone encountered a person using the "grass" or "ocean" OSX terminal themes in the wild? Why are they even there?
- hnlmorg 6y ago
  Not in macOS Terminal specifically but one of my colleagues in a previous job used similar themes to differentiate between different servers. Database servers would be one theme, dev web servers another, and prod web servers a 3rd theme. It was a system that worked well for him but not something I've felt compelled to emulate.
  - shiftpgdn 6y ago
    That's remarkably clever. Many years ago I accidentally destroyed a production server when I got terminal windows mixed up.
  - css 6y ago
    I do this with git repos: backend repo code editor and associated ttys share one theme, frontend another, and so on. Makes it very easy to know the context of what I am working with at a glance.
- mrweasel 6y ago
  Grass is actually pretty good, not that I use it. However, I do have a colleague who has a script which pick a "random" colour theme for each new terminal, one of which is pretty close to the "grass" theme. His script isn't truly random, but it does contain maybe twenty themes or so. During a normal day, he's working in 10+ terminals on various servers. The colours and placement of the terminals helps him to remember which server he's working on. So colours are only there to provide visual glue to help him determine the environment he's on, rather than being a personal preference for some theme. It doesn't matter that the grass theme is ugly, it's just the green terminal window which is currently an ssh session the stage database server.
megous 6y ago
You can also do this for Linux kernel console, if you implement export for vt.default_{red,grn,blu} kernel command line parameters. https://elixir.bootlin.com/linux/latest/source/Documentation/admin-guide/kernel-parameters.txt#L5584 https://elixir.bootlin.com/linux/latest/source/Documentation... That would be very useful :) Or this: https://github.com/EvanPurkhiser/linux-vt-setcolors https://github.com/EvanPurkhiser/linux-vt-setcolors
gregsadetsky 6y ago
Congrats! Very small note: when changing any of the colors, the URL changes presumably to reflect the new state. The issue is that these "stateful" URLs don't work when accessed directly. Try this one that I got by fiddling with the colors a bit: https://terminal.sexy/#HR8hxcjGKCoupUJCjJRA3pNfX4GdhWePXo2HcHiAXXyqzGZmtb1ogWo-gaK-spS7ir63xcjG https://terminal.sexy/#HR8hxcjGKCoupUJCjJRA3pNfX4GdhWePXo2Hc... The site hangs and does not initialize. Cheers (I just emailed the site's author about it being discussed here as well)

92 points by rohan1024 6y ago

A note to any developers writing console applications, please please please don't use RGB values in your terminal colour -- only use the 8 base colours plus highlight. RGB values prevent your users terminal from using the custom colour palettes your users might define (and like this site helps you to create). Aside from being a little annoying, it can cause genuine usability problems for some groups of people who use custom palettes: - for visual impairment reasons (eg high contrast colours) - or to differentiate different servers (eg different background colours for dev or prod servers) - or have less contrasting colours to reduce eye strain (eg the Solarized colour schemes) - might suffer from colour blindness so pick colours that contrast better with their condition - or even just those that prefer a white or other non-black backgrounds for readability reasons (eg they might be dyslexic and find a non-black background or different shades of text easier to read). I do fall into two of those categories and run into this issue a lot since there is a trend these days for developers to hard code colour values into their applications. Equally, some developers use the "you can select a custom colour map - I just define a pretty default" argument and while that's slightly better, the best option would be still to default to the standard 8 colours (or the default unformatted text) and let users opt into RGB values if they wish. This will save your users from constantly having to define the same colour palettes in every application.

DarkWiiPlayer 6y ago
Default to standard terminal colours and allow customization if necessary (I think vim handles colours very nicely :D)
- hnlmorg 6y ago
  > Default to standard terminal colours That's my point :)
JdeBP 6y ago
As I noted at https://news.ycombinator.com/item?id=22002036 https://news.ycombinator.com/item?id=22002036 . (-: It has been really 16 colours since the days of AIXTerm, even though that did not get formally standardized. Only a couple of places nowadays make the error of conflating bold and bright. It's not really "8 base colours plus highlight" at all, and that's certainly not the case with the tool at hand. You are also approaching being a decade late with a plea not to use direct RGB colour. https://gist.github.com/XVilka/8346728 https://gist.github.com/XVilka/8346728 started in 2014, for example. What the tool at hand really tells us is that there are already at least 18 different ways of specifying a colour palette. Perhaps the better idea nowadays is to promote a common 16-colour-to-RGB palette mechanism for TUI applications, akin to mailcap or something.
- a1369209993 6y ago
  We have a common 16-color-to-RGB mechanism: write \e[34m or similar and let the terminal do its damn job.
  - JdeBP 6y ago
    No, you do not have that. For starters, it's still a matter of debate whether the world is wholly ECMA-48:1976 yet. There are people who contend that we cannot assume universal adherence to a 1976 standard. * https://unix.stackexchange.com/q/548158/5132 https://unix.stackexchange.com/q/548158/5132 * https://unix.stackexchange.com/a/5802/5132 https://unix.stackexchange.com/a/5802/5132 Then there's the matter that only colours 0 to 7 are in fact standardized in ECMA-48. That's 8 colours, not 16. The AIXTerm mechanism has never been standardized, and what has been standardized in the likes of ITU T.416 is both not the AIXTerm mechanism and badly implemented to the extent that people are still today pushing for two long-standing mistakes to be corrected by software authors. Moreover, not every terminal agrees on how to interpret even the non-T.416 SGR control sequences. Famous and still widely used terminal emulators, such as the Linux built-in one for its KVTs, respond to boldface (SGR 1) by changing colour; in contrast to many terminal emulators where boldface means boldface and isn't a colour change. The control sequences are not the same and cannot be hardwired. * https://unix.stackexchange.com/a/608930/5132 https://unix.stackexchange.com/a/608930/5132 Personally, I am of the opinion that one can nowadays assume ECMA-48:1976 at minimum as long as one allows for "dumb" as well. But that doesn't mean further assuming the AIXTerm 16-colour mechanism. Until you go and change the Linux KVT's (and others') handling of boldface, and then the "linux-16color" entries in termcap and terminfo, to actually match your claim, your claim will remain incorrect. (Also note the caveats at https://news.ycombinator.com/item?id=23752827 https://news.ycombinator.com/item?id=23752827 .) Then there's the fact that a decent common TUI palette system wouldn't be 16-colour-to-RGB, because that would still need a second map. It would be better than that. That's just a barebones concept. It would be display-element-to-RGB, learning from the design of GUI palettes back in the 1980s, where the colour schemes specified colours for abstract UI elements such as "window title", "pressed button", "file", "directory", "text label", and the like. And indeed from the design of Borland TurboVision, which did the same.
a1369209993 6y ago
> only use the 8 base colours plus highlight. Those are actually called "RGBI"[0] colors (which would make the 8 base colours "RGB", though I haven't seen that usage), although that's clearly not what you mean by "RGB values". 0: 1 bit each for red,green,blue,intensity: #(r·AA+i·55,g·AA+i·55,b·AA+i·55)
- hnlmorg 6y ago
  No, the colours I'm talking about aren't defined as RGBI values. Wikipedia has good introduction to the different SGR colour parameters: https://en.wikipedia.org/wiki/ANSI_escape_code#Colors https://en.wikipedia.org/wiki/ANSI_escape_code#Colors I'm talking about 3/4-bit (8/16 colours) not 8-bit (256 colours) nor 24-bit ("true colour"). The 3/4-bit colour palette is configurable in most terminals. True colour is not.
  - a1369209993 6y ago
    I'm talking about the 4-bit (RGBI) ANSI color palette, used by \e[34;44;94;104m escapes. 8-bit or 24-bit color should not be supported by terminals in the first place (and certainly shouldn't be used by terminal applications), for the reasons you mentioned above.
    - da39a3ee 6y ago
      I think both of you are talking about the same thing. Please don't assume that your views are generally held or will meet with general approval. I think what you're saying is completely wrong and wildly inappropriate. In general, there will exist many terminal applications where the designers should feel absolutely free to use 256 and full-RGB colors if they wish to, seeing as the technology has supported it for years. An example is color themes for syntax highlighting; the designers of color themes obviously _can_ restrict themselves to 16-color palettes (e.g. https://github.com/chriskempson/base16 https://github.com/chriskempson/base16) but they are perfectly free not to. I do not understand what makes you think you have the right to demand that people impose such a vast restriction on terminal applications. The web supports 256 colors and full RGB; why shouldn't terminal applications?
lokedhs 6y ago
In addition to what you are saying, I'd also ask developers to not use escape sequences directly but instead use terminfo. It allows you to send the correct terminal sequences regardless of the type of terminal you use. In particular, it allows your users to completely disable the highlights by using TERM=dumb. Also, please check if the output is a tty (the isatty libc call) I don't know how many applications with fancy coloured output that looks completely broken when redirecting to a file.
da39a3ee 6y ago
> please please please don't use RGB values in your terminal colour Can you clarify what your suggestion is please? I assume you're talking about ANSI color escape sequences. There are 3 different ways colors are represented using ANSI color escape sequences (see https://en.wikipedia.org/wiki/ANSI_escape_code#Colors https://en.wikipedia.org/wiki/ANSI_escape_code#Colors) 1. Using the 16-color palette which is dynamic and under user control. 2. Using the 256-color palette, which are hardcoded colors. 3. Specifying 24-bit colors (RGB), which also hard-coded colors. Are you asking developers of terminal applications to use neither (2) nor (3)? If so, that seems like an extraordinary, and inappropriate, request. I do hope however that developers of terminal applications make it possible to configure the application to use (1). For example, do you disapprove of the existence of all syntax highlighting color themes unless they use only the base 16 colors?
- 0xffff2 6y ago
  Not OP, and not constrained by any accessibility needs, but restricting your terminal applications to (1) sounds entirely reasonable to me. At the very least, (2) and (3) should be entirely opt-in, never defaults.
  - kergonath 6y ago
    Or specific uses (someone else thread mentioned image rendering; I really like the sixel terminal in gnuplot to eyeball stuff from a server without bothering with X; there are plenty other uses for high-resolution full rgb graphics in a terminal).
  - da39a3ee 6y ago
    What about syntax-highlighting color themes? Although a subset of color themes (e.g. base16) are specifically designed to use the dynamic 16-color palette, my understanding is that it's routine in the color-theme world to allow yourself to hardcode colors from the 256-color palette. So an application making use of syntax-highlighting color themes would certainly make 256 color support default, wouldn't it?
    - 6y ago

jaquers 6y ago

Really well done application with tons of export / import formats, lots of presets and the palette is integrated into the UI - delightful. Thanks for the submission.

kergonath 6y ago
Indeed. And a great use of the .sexy TLD.
- cptnapalm 6y ago
  Sadly, it triggers my work's block filter.

shiftpgdn 6y ago

Vaguely off topic but has anyone encountered a person using the "grass" or "ocean" OSX terminal themes in the wild? Why are they even there?

hnlmorg 6y ago
Not in macOS Terminal specifically but one of my colleagues in a previous job used similar themes to differentiate between different servers. Database servers would be one theme, dev web servers another, and prod web servers a 3rd theme. It was a system that worked well for him but not something I've felt compelled to emulate.
- shiftpgdn 6y ago
  That's remarkably clever. Many years ago I accidentally destroyed a production server when I got terminal windows mixed up.
- css 6y ago
  I do this with git repos: backend repo code editor and associated ttys share one theme, frontend another, and so on. Makes it very easy to know the context of what I am working with at a glance.
mrweasel 6y ago
Grass is actually pretty good, not that I use it. However, I do have a colleague who has a script which pick a "random" colour theme for each new terminal, one of which is pretty close to the "grass" theme. His script isn't truly random, but it does contain maybe twenty themes or so. During a normal day, he's working in 10+ terminals on various servers. The colours and placement of the terminals helps him to remember which server he's working on. So colours are only there to provide visual glue to help him determine the environment he's on, rather than being a personal preference for some theme. It doesn't matter that the grass theme is ugly, it's just the green terminal window which is currently an ssh session the stage database server.

megous 6y ago

You can also do this for Linux kernel console, if you implement export for vt.default_{red,grn,blu} kernel command line parameters. https://elixir.bootlin.com/linux/latest/source/Documentation/admin-guide/kernel-parameters.txt#L5584 https://elixir.bootlin.com/linux/latest/source/Documentation... That would be very useful :) Or this: https://github.com/EvanPurkhiser/linux-vt-setcolors https://github.com/EvanPurkhiser/linux-vt-setcolors

gregsadetsky 6y ago

Congrats! Very small note: when changing any of the colors, the URL changes presumably to reflect the new state. The issue is that these "stateful" URLs don't work when accessed directly. Try this one that I got by fiddling with the colors a bit: https://terminal.sexy/#HR8hxcjGKCoupUJCjJRA3pNfX4GdhWePXo2HcHiAXXyqzGZmtb1ogWo-gaK-spS7ir63xcjG https://terminal.sexy/#HR8hxcjGKCoupUJCjJRA3pNfX4GdhWePXo2Hc... The site hangs and does not initialize. Cheers (I just emailed the site's author about it being discussed here as well)