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.
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?
This is a weirdly specific edge case and it really depends on what type of application is using the syntax highlighting.
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.
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.
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.
> 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),
`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).
> `bat` is one of the examples of when 256 and true colour shouldn't be used. [...] 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.
I believe that all your complaints would be solved if you set the env var
BAT_THEME=base16
right? (Or indeed ansi-light or ansi-dark; none of those themes use hard-coded colors).
> 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.
> I believe that all your complaints would be solved if you set the env var
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.
I don't user a terminal-based editor very often, but my vim syntax highlighting uses the basic 16 colors and it works just fine for me. Personally I think a lot of syntax highlighting is noise anyway. But again, I don't really have a problem with more colors being an option. There are few things that I love more than tweaking and customizing my editor. I just want the out of the box configuration to be dead simple. Any number of options is fine, but your application damn well better display correctly regardless of my color settings, which is so much more likely if you stick to using the 16 colors I get to manage myself.
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).