On Syntax Highlighting

Yihui Xie 2017-07-06

I have been asked several times to improve certain details in syntax highlighting (e.g., this one, and this one), and I usually say no. It is not that these issues do not exist, but I don’t think they are worth the effort. To me, syntax highlighting is only for cosmetic purposes. Colors make me feel more engaged in reading source code. It will be boring to read source code without colors. However, I don’t really care if syntax highlighting tools do a precise job or not. I’m totally okay if certain keywords are not correctly identified or highlighted. Compared with what specific color is applied to an operator, I care much more about whether there are spaces around the operator.

My favorite syntax highlighting library on the web is highlight.js. I think its author has done a very good job at saying no to the feature request of adding line numbers to code blocks. I very much agree with him that many syntax highlighting libraries are overdoing the job.

Don’t get me wrong. I don’t say no to all issues related to syntax highlighting. For example, when certain characters are simply eaten by the syntax highlighter, it is certainly a legitimate issue that has to be fixed, because it is not about the appearance of the code but it has changed the content of the code.

Some users also often request a level of syntax highlighting that looks too heavy in my eyes. To me, too much syntax highlighting is probably not so different with no syntax highlighting at all. For example, Will Landau wanted crayon colors in knitr output, and personally I have no interest in supporting it. Similarly, Kevin liked syntax highlighting operators in code, but I didn’t think it was very important.