Design, edit and share custom terminal color schemes(terminal.sexy) |
Design, edit and share custom terminal color schemes(terminal.sexy) |
- 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.
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 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.
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.
That's my point :)
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)
Wikipedia has good introduction to the different SGR colour parameters: 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.
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)
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?
* https://github.com/jdebp/nosh/blob/79b1c0aab9834a09a59e15d47...
* http://jdebp.uk./Softwares/nosh/guide/commands/TerminalCapab...
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/#HR8hxcjGKCoupUJCjJRA3pNfX4GdhWePXo2Hc...
The site hangs and does not initialize.
Cheers
(I just emailed the site's author about it being discussed here as well)
https://elixir.bootlin.com/linux/latest/source/Documentation...
That would be very useful :)
Or this:
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.
Thanks for the submission.
* https://unix.stackexchange.com/q/548158/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
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 .)
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.
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) 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?
And the web suffers from all sorts of accessibility problems because developers don't take that into account. Native applications (and I'm not talking about Electron) is a better example -- Microsoft and Apple have taken accessibility concerns into account and created interface toolkits that aren't a rainbow of colours by default and which users can easily customise one colour scheme in the systems control settings to affect all native applications.
Using 256 or true colours in console applications break the terminals ability to apply the user-defined colour palette and that can bring accessibility issues with it (as well as being a little annoying for anyone who happens to prefer non-black backgrounds).
For example if it's designed to be a generic `cat` or `man` type utility then I'd suggest sticking with 16 colours. However if it's intending to be a fully featured TUI IDE then something like that would expect the user to configure the application before using it in any significant way and thus using 256 or true colours is more reasonable.
As it happens, I have actually implemented syntax highlighting into one of my open source projects and I stuck with the 16-colour palette. There's only so many unique colours you'd want to use before the screen becomes a mess anyway.
But, they do not default to 16-color palette: for example, bat's default theme is Monokai Extended (https://github.com/jonschlinkert/sublime-monokai-extended).
So, as politely as possible, I do suggest that you should get off your high horse; yes people recognize the importance of supporting the 16-color palette but no, it's not some sort of obviously evil abomination to support and even default to hardcoded 256-colors and RGB colors. Quite to the contrary, there are several use cases among modern, popular, terminal applications. They involve color-rich scenarios such as syntax highlighting.
Don't get me wrong though, we're largely in agreement. I wouldn't want a normal terminal app to hard-code, say, a yellow color, which is only visible to users of dark terminal backgrounds, but hopeless on a white background.
So what do you suggest, that the web should use a limited palette that is user-configurable and not hard-code any colors?
I really want to say the following politely and respectfully, so please try to see it in that light: there is an upper limit to the restrictions that it makes sense to impose in the name of accessibility. There have been some awful acts of vandalism done by accessibility zealots. I'm thinking in particular of the deletion of thousands of hours of university lectures by UC Berkeley.
`bat` is one of the examples of when 256 and true colour shouldn't be used. I have a huge amount of respect for that application, it's a well polished utility, but I found I couldn't always use it with my accessibility themes turned on and configuring it to work on different terminals and on different machines got tiresome enough that it no longer became a productive tool. Again, I otherwise have a huge amount of respect for the utility.
As I said in my previous post, I have actually written a terminal application that applied syntax highlighting and I didn't need more than 5 unique colours so it still looked good in the standard 16 colour palette. It even optionally supported underlining misspelt words. The whole thing is easy to read, easy to reason and respects the output preferences defined in a given user's $TERM.
Developers don't need 265/true colour palettes. It doesn't add anything to the application (unless the point of the application is rendering graphics in text mode) yet it does cause issues for a great many users. So I don't think it's an unreasonable point to raise.
> So, as politely as possible, I do suggest that you should get off your high horse;
Asking for accessibility in productivity tools is not mounting "a high horse". It's just asking for a little courtesy for lesser abled users. But even accessibility aside, it's daft for developers to assume that everyone is running their $TERM with a black background. There's plenty of terminal emulators that default to white backgrounds and plenty of people who have others colours in between (as discussed elsewhere in this submission, some people use colours as a sanity check so they know which terminal session is which).
> Don't get me wrong though, we're largely in agreement. I wouldn't want a normal terminal app to hard-code, say, a yellow color, which is only visible to users of dark terminal backgrounds, but hopeless on a white background.
But that's exactly the scenario you're advocating by suggesting developers should use colours that cannot be remapped in the terminal. And it's exactly the scenario I run into time and time again (hence my post).
I believe that all your complaints would be solved if you set the env var
BAT_THEME=base16
> Asking for accessibility in productivity tools is not mounting "a high horse"
Can you see my confusion though. Look again at your language (and your italics):
> `bat` is one of the examples of when 256 and true colour shouldn't be used.
You appear to be not asking for accessibility but saying that bat shouldn't support color themes that make use of 256 colors. And that is where you are transitioning from perfectly reasonable to perfectly unreasonable :) It's not up to you how other people use their terminal. If they like using more than 16 colors then that is perfectly alright and none of your business.
As I mentioned above, that transition from asking for (even "demanding" would be fine) accessibility to cutting off other people's noses to spite their faces is where accessibility concerns have unfortunately led to terrible vandalism: the removal of thousands of hours of video lectures from the internet by UC Berkeley.
And then you have two problems...and program that, by default, doesn't respect the terminal defaults and an env var you now need to replicate across every environment you use that tool on.
> Can you see my confusion though
No, I can't. I've been really clear right from the outset.
> You appear to be not asking for accessibility but saying that bat shouldn't support color themes that make use of 256 colors.
Exactly. Using terminal defaults is better for accessibility. I mean I have no issues with tools optionally supporting 256 or true colours, but don't make that the detault.
> It's not up to you how other people use their terminal
Exactly. Hence why developers should write tools that respect other peoples terminal defaults. If they use 256 or true colours then they're dictating how other people should use their terminals.
> If they like using more than 16 colors then that is perfectly alright and none of your business.
So support it as an optional extra. Just don't make it the default -- instead respect the other peoples terminal preferences by using the terminal defaults.
> accessibility concerns have unfortunately led to terrible vandalism: the removal of thousands of hours of video lectures from the internet by UC Berkeley.
That's a ridiculous edge case and has nothing what-so-ever to do with my polite request. I'm not asking people to remove content, just to respect peoples terminal defaults.