... at least when it comes to Markdown files ;)
Originally published on my blog.
Introduction: editing this blog in Neovim
Here’s what it used to look like to edit one of my articles in Neovim:
Take a quick look. Do you see what’s wrong?
First, the line about the
summary
in the front matter is colored in green. The front matter uses YAML syntax, but Neovim does not know it and thus highlights this line incorrectly.Second, the python code is OK, but the language name is misspelt:
pyton
instead ofpython
. I am using Neovim’s built-in spell checker, but since Neovim “knows” the stuff after the three backticks is source code, it disables spell checking for this part of the text.Third, the link to ‘Using CMake and Ninja’ is built using hugo syntax, and if you were extra careful you may have noticed that the path to the article after
ref
starts with a double quote ("
), but ends with a single quote ('
).
Turning syntax highlighting off
For quite some time I did not think to much about this situation, until I read A case against syntax highlighting, by Linus Åkesson.
So one day I decided to try to turn the syntax highlighting off:
- This time, the spell checker checks everything, and the typo in
pyton
is caught. - The “rendering bug” of the front matter is gone.
- Also, he problem with the single quote is more obvious to spot. It’s less likely to be distracted by all the colors. That one may be subjective: it’s what my guts tell me, though.
One more thing: I’m also viewing the rendered HTML in a browser next to my Neovim window. Hugo rebuilds the page I’m editing after each save, and the browser automatically reloads.
This has several consequences:
First, some parts of the highlight are redundant. I’m able to see the italics in the browser, I don’t need to also view them as such in the editor.
Second, the problem with the
{{ref
usage gets caught by thehugo
process itself:
ERROR 2018/10/04 16:36:23 error processing shortcode
"_internal/shortcodes/ref.html"
for page "post/0087-demo-syntax-highlight.md":
template: _internal/shortcodes/ref.html:1:89:
executing "_internal/shortcodes/ref.html" at <0>:
invalid value; expected string
So let’s think about what we learned:
- The syntax highlighting is buggy, and it will never be as good as the HTML rendering. (Especially with Markdown, where each rendering tool has its own quirks).
- It “hides” important information, like spelling errors
So, why do we keep using it?
Conclusion
For now, I’m just turning syntax off for Markdown files. Here’s the relevant section in my init.vim
file:
augroup textfiles
autocmd!
autocmd filetype markdown :setlocal spell spelllang=en | syntax clear
augroup end
I’m still using syntax highlight in the other cases.
But, in the same way the syntax highlighting may be useless (and even harmful) for editing Markdown when a HTML renderer can be used, maybe syntax highlighting is also useless if a linter can be used directly to check the code while it’s being typed.
Food for thought …
I'd love to hear what you have to say, so please feel free to leave a comment below, or check out my contact page for more ways to get in touch with me.
Top comments (7)
Isn't it simply a case of 'buggy syntax highlighting is useless'? In that case, 'syntax highlighting' becomes the least relevant part of the statement, compared to being the primary subject in the original version.
As for linter-during-typing, that only applies if you see syntax highlighting as a typing aid, which is arguably the least common usage.
In the linked blog post, the example of syntax highlighting applied to fiction is just a bad example because it's bad syntax highlighting regardless of whether the reader approves of syntax highlighting.
I agree with you about the weakness of the examples. Coming up with good examples is hard.
I'm not sure. Maybe they are downsides we don't even think about because we're so used to it.
Then, what is it? Is is just for readability? If so, is a well-written code with no colors more readable than badly written code with excellent coloring?
I completely agree. But without appropriate examples, it's all just voicing of opinions without evidence or argumentation.
The only one dowside I've heard of that makes the least bit of sense is that you get used to it and therefore would have trouble if you didn't have it anymore. But the same is true for mostly everything, and it's also highly hypothetical (for most developers at least).
Like the bad example in the linked blog post, this is also an unfair comparison: I'd rather have well-written code. Period. That's a matter that's entirely orthogonal to whether syntax highlighting has
value.
Also, the point of well-written code compared to poorly written code (assuming both of those do what they are supposed to), is exactly for readability, so 'just' doesn't really apply there.
It is slightly overstating it to say useless, but the value of syntax highlighting on a markdown file should be minimal even if properly implemented. If you were to find a markdown file which would benefit greatly from syntax-highlighting, I would say you found a markdown file that somehow manages to be unnecessarily complex.
Most often, I don't use markdown to write 'code' that I ever intend to transform into html. I use markdown as my medium for writing, taking notes, documentation, etc. I view these files in text editors and it is great to be able to have my eye drawn to headings and other bits of information when I go back to reference it.
You should specify in the title that it's neovim related. I have no problems with the syntax highlight of markdown in Visual Studio Code and also in Atom. Just works.
I just checked and you're right, VS code is better in coloring Markdown than Neovim:
Front matter is properly colored, and the spell checker finds the typo in
pyton
.But note the problem with the hugo-specific syntax remains the same.