|
OK, I think the problem was that your original post was much too strongly worded. It sounded like you thought that there was no role at all for 256-color and RGB ASCII escape color sequences. But that's clearly not true: just look at a terminal application like bat (a syntax-highlighting cat replacement), which is very popular, and uses sublime color themes most of which use hardcoded colors. In fact, nowadays, when I use the terminal applications that I use most frequently, I make use of their 256-color and full RGB capabilities. But, nevertheless, all the applications I have in mind allow the user to escape hardcoded colors and use the 16 color palette to be used. 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. |
`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).