I've noticed that a new, two-tone color scheme has gone into effect for formatted code on TeX.SE. Consider, say,
\documentclass{article}
or
\begin{table}
The commands -- \documentclass and \begin -- are rendered in pale orange (light brown?) and their arguments are rendered in an olive green if they're enclosed in curly braces. Maybe I should call it a "three-toned" color scheme, actually, since gray is used to denote comments.
While I commend the underlying thought, the implementation of the new color scheme leaves a lot to be desired. I'll mention just six [6!] issues; I have no doubt that there are more.
TeX comments, i.e., anything on a line after an un-escaped
%symbol, used to be rendered in a pale gray. But under the new color scheme, a much darker gray tone is used for comments. The new, darker gray is quite close to black. As a result, the visual distinction between commented material and everything else has pretty much vanished.As long as one isn't red-green color blind, the color scheme may "work" fairly well, but only for very simple use cases, such as the two shown above. However, the coloring does not operate correctly if a command name employs LaTeX3 syntax rules. E.g., in the command
\cs_new_protected:Nnonly
\csis rendered in pale orange, whereas_new_protected:Nnis not. I can only assume that this breakdown occurs because the coloring software has been "told" that only letters are valid in LaTeX command names -- and thus that_and:are not.Next, because LaTeX3-conforming macro names are not recognized properly, the argument --
sort-- in\keys_define:nn { sort }isn't colored in olive green.
There is more! Even if the argument of a macro is recognized as such, all of the argument is rendered in olive green. That's distinctly inferior for use cases such as
\newcommand\sorted[1]{\directlua{sorted(\luastringN{#1})}}because the TeX directives
\directluaand\luastringNare treated visually as if they were ordinary text.The coloring scheme for the argument of a command does not appear to handle nested curly braces (or other "fences", for that matter) correctly. If you look closely at how
\newcommand\sorted[1]{\directlua{sorted(\luastringN{#1})}}is rendered, you'll see that the final three characters --
)}}-- are not colored olive green. I can only assume that this is because the coloring software wasn't made aware of the fact that TeX directives can be nested. Hence,instead of looking for the}character that matches the initial{character, the coloring software just looks for the first instance of}.Last but not least: Was the new color scheme ever run past color-blind users?? I am not color blind myself, but my friends who have red-green color blindness tell me that they are essentially unable to distinguish between shades of red, orange, and green -- especially if the shades are a bit subdued -- as is the case with olive green and brownish orange.
Do the powers-that-be at StackExchange have no staff, test users, or other acquaintances who are red-green color blind and could have raised a warning flag?
Question: Until the powers-that-be get around to fixing these issues, is there a way to revert to the previous color scheme? Alternatively, is there a way to turn off coloring entirely -- and get a look similar to what's (still) in effect on Meta.TeX.SE? In my view, no colors at all would be distinctly preferable to the dismally inadequate color scheme that's been foisted on us.
