17

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:Nn
    

    only \cs is rendered in pale orange, whereas _new_protected:Nn is 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 \directlua and \luastringN are 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.

10
  • 1
    Its not just a new color theme, it's a new syntax parser (related question). It is weird, that the auto-detection of the language LaTeX does not seem to work on Meta (but it does on the main site). If you explicitly state the language, the highlighting is the same here, though.
    – schtandard
    Sep 26 '20 at 10:46
  • 1
    @schtandard There is no "auto-detection". On the main site, latex is just the default value if no language is given. Meta does not have this default value. Sep 26 '20 at 11:00
  • @samcarter_is_at_topanswers.xyz and schtandard - Thanks for these observations. Curiously, code type autodetection appears to have been switched on for Meta as well, likely just a few minutes ago.
    – Mico
    Sep 26 '20 at 11:05
  • 1
    @Mico Based on the timing my best theory is that they forgot to close the monkey cages before they all left for the weekend and now the monkeys have fun messing with the code highlighting :) Sep 26 '20 at 11:08
  • 1
    This comment summarises it nicely: meta.stackoverflow.com/questions/401553/… Sep 26 '20 at 11:14
  • 2
    see also meta.stackexchange.com/questions/353983/… (and David reported an issue there already). Sep 26 '20 at 11:14
  • 1
    Is the backslash before a command supposed to be in the same colour as the command? I think it should. (TeX Studio keeps the backslash in the same colour.) Sep 27 '20 at 15:54
  • 3
    @ApoorvPotnis - I fully agree with you: In TeX and LaTeX, control words consist of both the backslash and the subsequent letters/characters.
    – Mico
    Sep 27 '20 at 15:59
  • 2
    Why would you expect the people developing a site whose biggest section is SO would know anything at all about software development and testing? This is about what you would expect from the mindset that "programming" is just cargo-cult "cut and paste whatever Google tells you might work".
    – alephzero
    Sep 30 '20 at 16:51
  • @alephzero - Your diagnosis is spot-on. The developers of the new coloring scheme show neither any awareness of the practical needs of the users of TeX.SE nor the slightest interest to enter into a dialogue with users of TeX.SE to determine what might be a usable color schemes. The developers have learned nothing, but absolutely nothing, from the various self-inflicted fiascos of the past. Deep sigh.
    – Mico
    Sep 30 '20 at 17:00
8

Looking at https://tex.meta.stackexchange.com/editing-help there is apparently a way to specify that no syntax highlighting should take place by specifying

<!-- language: lang-none -->

at the beginning of the post and then you can get

\keys_define:nn { sort }

as desired.

2
  • Many thanks for providing this link and for pointing to the <!-- language: lang-none --> fix. I've gone ahead and added this meta directive to my most recent dozen [yes, 12] answers. (If time permits, I'll extend the fix to my most recent 100 answers.) In my view, no color scheme at all is eminently preferable to a poorly conceived and poorly implemented color scheme.
    – Mico
    Sep 27 '20 at 6:53
  • I've also gone ahead and applied the <!-- language: lang-none --> meta directive fix to all o my answers that have 100 or more upvotes.
    – Mico
    Sep 27 '20 at 8:25
9

Hmmm... looking around after posting in Meta I found this in the highlight.js site:

«At best I'd consider our Latex support to be more of a "placeholder" than a real grammar... If someone would like to pitch in here to help I'd be more than happy to answer any HLJS specific questions about our grammars, etc.»

2
  • 3
    "Placeholder" is a rather generous euphemism, isn't it? Many LaTeX code blocks now look as gaudy as zealously over-decorated Christmas trees.
    – Mico
    Sep 28 '20 at 19:32
  • 6
    @Mico Your comment is an insult to Christmas trees :) i.stack.imgur.com/fVZXV.png Sep 29 '20 at 8:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .