
A case against syntax highlighting (2007) - hellofunk
http://www.linusakesson.net/programming/syntaxhighlighting/
======
savanaly
>Well, no. One of the basic rules of thumb in typography is that, when writing
a piece of text, you should choose one typeface and stick to it. Likewise, a
splash of colour may grab the reader's attention, but it will inevitably
decrease the legibility of the text. The natural flow of the text is broken,
and it takes more brain effort to piece together the individual letters into
words and semantics. Cognitively, the reading process becomes slightly less
automatic and slightly more conscious; leaving less room in the conscious part
of the mind for actually understanding the text.

That might be true for text, but I don't read code at all the way I read
prose. I highly doubt i've ever read more then four or five lines of code in a
row without my eye jumping to other parts of the function, forward to the next
part to understand why variables are being set up, or backwards to remember
when such variable was defined, or jumping to the big picture to remember how
this function or that fits into the overall program. Syntax highlighting is
enormously helpful to my eye when reading in that manner.

~~~
bpchaps
Yes, and that's your opinion. Not mine. Not his.

It's an opinion piece, but you and just about everyone in this thread is
writing as if their opinion is a fact that trumps his opinion. Stop that :(.

Edit: Why the downvotes? Are different opinions really that bad?

~~~
Nadya
_> Do you rely on syntax highlighting when developing software? If so, you may
be shooting yourself in the foot. In this post, I will argue that syntax
highlighting, while aesthetically seductive, moves focus from content to form,
and discourages those who look at the code from trying to understand it._

The very first opening line is an argument against syntax highlighting.
Arguments (at least, of this sort) should be based on facts or studies, or at
least logical reasoning and it is not introduced as an opinion piece, but an
argument.

I only gave the article a glance and I take two issues with it.

 _> Syntax highlighting applied to fiction. It's easy to spot all the verbs,
but why on Earth would you want to do that?_

I wouldn't need to for English, however I can think of a situation where I'd
like to see the difference between an int '5' and a string '5' at a glance. In
fact - that sort of bug isn't all that uncommon in languages that aren't hard
typed.

 _> [misguided piano teachers, yellow keys]...but do they honestly believe
that children are unable to learn note names? They will have to, eventually,
and then they will have to un-learn the colours._

This argues like a case against mnemonics as learning devices. Mnemonics are
an entire memory trick designed to be "un-learned" by the learner. Planet
names aren't difficult to learn but a sentence like "Mercury Viewed Earth’s
Many Aspects Joyfully Sitting Under Neptune" sure makes the order from the sun
easier to remember. Mnemonics are a pretty well-research thing and they work
[0]. Most people who want to compete in memory contests rely on using them. My
favorite example is the Major System [1].

[0]
[https://en.wikipedia.org/wiki/Mnemonic](https://en.wikipedia.org/wiki/Mnemonic)

[1]
[https://en.wikipedia.org/wiki/Mnemonic_major_system](https://en.wikipedia.org/wiki/Mnemonic_major_system)

~~~
bpchaps
He's making arguments against it, yes. But he's not saying it as a piece of
fact. I can see why you think that, but it's still an opinion piece.

For me, syntax highlighting is a crutch that I want to avoid. I find myself
glancing at my code rather than actually reading my code when it's enabled.
It's an incredibly refreshing feeling to turn it off and just go back into vi.
My code becomes shorter, easier to read, faster and much easier to maintain.

~~~
acbabis
I can't argue with that, but shouldn't you want to _eventually_ take off the
training weights so you can go that much faster?

~~~
bpchaps
I do all the time. I spend a significant portion of my time using Jupyter,
which has syntax highlighting and other 'improvements'. I really dislike it.
Then again, I'm within a shell in tmux all day, so...

------
joslin01
> It's easy to spot all the verbs, but why on Earth would you want to do that?

The big difference between genuine reading and coding is the variability of
scanning / focus. When you read, you usually want to take it all in -- it
wouldn't make sense to jump around because it's a single, linear journey.

Code does not observe this rule, so the more experience you get as a coder,
the better scanner you become. You quickly view a class and think "ah yes
yes.. it's _roughly_ doing this.. that" \-- you sure as heck don't read the
whole thing carefully word by word! The best coders are amazing scanners --
capable of pointing out a missing parenthesis in a sea of parenthesis. This
argument against syntax highlighting is like taking the batteries outta our
flashlight. Sure, we'd be more careful but our productivity would surely
suffer.

~~~
oconnore
I've been working without highlighting for ~6 months, and I've gotten faster
at scanning, not slower.

Feel free to keep doing what you're doing, but making assumptions about
workflows that you're unwilling to try is not helpful or convincing.

~~~
joslin01
I want you to know this comment is every bit as subjective and "not helpful /
convincing" as you think mine is except mine had deductive reasoning -- yours
is just anecdotal. I only been coding for 10 years, so maybe some veterans who
been coding since the 70s can share their experience and we can weigh it
against yours.

I also question that you indeed are a faster scanner. Here's a specific
example I wonder if your scanning would win out on -- Xcode turns internal
Cocoa classes blue whereas your own classes are green. You quickly know what
you coded and what you didn't. Not helpful? Should already know? I wonder if
you inherited someone else's code base if you would enjoy the green immediate
feedback rather than the inference you would otherwise have to take.

------
elcapitan
What people usually get wrong about text and typography is that there is not
just one type of text, and therefore not just one type of typography.
Dictionaries have different typography from recipe books, which are different
from math books, which are different from newspapers and so on. So saying that
source code should not have its own kind of typography because it wouldn't
work for some other textform is like saying that encylopedias should be like
novels because it would be silly if there were arrows in front of words in
novels that appear somewhere else in the book.

------
dahart
Heh. The example of highlighting = vs == different just proves the value of
syntax highlighting for me. Misspelling keywords is the same thing, a
highlighting (or lack thereof) can alert you to the fact that you flubbed the
spelling, and save you from a compile or runtime error.

Programming language keywords are different than English verbs. If you
misspell keywords, your program will fail, but if you misspell a verb in an
essay, nothing catastrophic happens, most of the time.

It does take me longer to read code in an uncolored ssh window than in Sublime
with syntax highlighting, that's true. And I agree that semantics are more
important than syntax. But I'm not sure I buy that having highlighting makes
reading colored code slower than it would be otherwise. The case here didn't
present evidence that it's worse. It might be a crutch, but it's also possible
that the reason reading uncolored code is slower is because having syntax
highlighting is actually better than not having it.

~~~
nv-vn
Misspelling a keyword is a low-cost issue. The compiler will point it out to
you immediately, and compilers are very fast these days. Nothing happening
here is very catastrophic.

~~~
woodman
The fastest I've ever seen clang compiled, with ccache and in memory fs, was 7
minutes - which is a long time for a syntax check. Just browse any buildbot
dashboard. You could use libclang for interactive evaluation - but boy does it
suck when the file that you're working on pulls in a page of headers. What
you're suggesting is fine for anything that results in an executable named
a.out, but it doesn't work for non-trivial software projects.

~~~
nv-vn
Misspelling the keyword happens relatively early in the compiler pipeline
(during parsing). If your build hasn't changed very significantly (i.e.
something along the magnitude of <1000 lines changed that aren't scattered
across tons of files) it should warn you within a few seconds. Anything else
is a failure in the design of the compiler or build system. (In fact, outside
of C or C++ compilation is usually much, much faster than what you cite). Non-
trivial projects in better-designed languages can easily take a tiny fraction
of that time.

~~~
woodman
> If your build hasn't changed very significantly...

Change one character in one file that gets linked at the end of the build, the
syntax check would go from 7 minutes to 3.5 on average - still too slow.
You're also overlooking conditional compilation, your change might break the
build on another platform - the syntax won't be checked until it hits the
buildbot that flips the right flags.

> Non-trivial projects in better-designed languages...

Ah, the lets redo-everything-in-x school of thought - good luck with that.

------
btilly
I understand the spirit, but it is wrong.

Syntax highlighting is helpful to me for the following purposes.

1\. Scanning through code.

2\. Making it clear what is a comment, what is a string, and what is code.

3\. Catching a variety of minor syntax errors automatically. (For example
failing to properly close a multi-line quote...)

4\. When switching languages, reminding me when I didn't fully switch gears
and wound up using the wrong keyword.

I learned to program in vi without syntax highlighting. Before I tried syntax
highlighting, I thought it was silly. After I tried it, I found it made for a
more comfortable environment. The difference isn't huge, but it is noticeable
enough that now I always turn it on.

~~~
hosh
I have a similar experience. I learned to program as a kid with BASIC (no
editor). I learned to read code while I was young because I was too lazy to
type the BASIC games found in magazines, so it was easier to parse the game
and play it in my mind. I cut my teeth on the MudOS platform, using the in-
game `ed` to for rewriting backend code. I didn't use syntax highlighting for
a long time.

There are times when I log into a system to edit something with vim, and no
syntax highlighting appears. It surprises me, but not a deal-breaker.

I also thought syntax highlighting was unnecessary. The first time I saw a
video of using the Twilight theme for Sublime, I was stunned by what the
colors brought out. At that time, my awareness was not as developed, so I
couldn't even tell you I liked it because of how I experienced the code.

So I spent a lot of time finding good themes for my editors, first vim and now
spacemacs. If I am going to look at code all day, I don't want my eyes to
bleed. Aesthetics is the strongest argument I have for syntax highlighting,
and it should not be casually dismissed without investigation.

~~~
btilly
Aesthetics matters a lot. Here is a simple example. Light text on a dark
background tends to be more readable, but may depress some people. Dark text
on a light background is the opposite.

It sounds stupid, but it matters.

------
chc
This whole article appears to be based on a misunderstanding (or at least an
idiosyncratic view) of typography.

Varying styles within a work can be immensely helpful, and is almost
universally done. For example, headers tend to be written bigger to indicate
a) that they're something different from the main text, and b) what their
relationship to the main text is. Similarly, italic and bold text are used to
impart additional meaning to various parts of the text. Many publications will
use a different style for things like bylines and photo captions — again,
because they are different things from the body text and this helps the reader
pick out the parts of the page in a purely visual manner. It's even common to
see parts of the body text stylized differently to indicate that they have a
special function — for example, in a Q&A format, you'll often see the
questions formatted differently from answers, or the identities of the
speakers might be written differently from the words they said.

So not only is this philosophy about typography not necessarily applicable to
code, it's not even widely accepted for ordinary written text.

------
ajkjk
Apparently I'm supposed to believe

"Perhaps syntax highlighting was invented to speed up the reading process. ...
Well, no. One of the basic rules of thumb in typography is that, when writing
a piece of text, you should choose one typeface and stick to it"

and then believe the rest of the article. Well, I don't believe that part,
since I experience the complete opposite every day. A silly typographical
guideline doesn't affect my experience at all.

------
bww
> One of the basic rules of thumb in typography is that, when writing a piece
> of text, you should choose one typeface and stick to it.

Right, because prose text never uses more than one type size, treatment, or
formatting to make the content easier to read.

------
stevebmark
Not this again.

"A case against traffic lights having colors. You should just pay more
attention to what each dot means"

~~~
gingerrr
This is the best pithy response to this argument I've seen, thanks. Can't wait
to bust it out next time.

------
Philipp__
I think that comparison between text and code is wrong! Totally! But maybe it
depends how you experience code, it makes sense that it affects your
preference to syntax highlighting. And I do not like how he took personal
preference and tried to generalize it. If something works for you, doesn't
mean it will work for everybody, nor that it can be scientifically true. I
know what OP wanted to say, but I think we should stop with those deep minded
subconscious thinkings that affect our code.

I like syntax highlighting it, it helps me. Not some over the roof-rainbow
colors, I always like minimal and dark color schemes, but I think it would
definitely feel weird to code without syntax highlighting. Although I would
get used to it. But if it ain't broken don't fix it.

~~~
masterzora
I think comparing text and code actually makes perfect sense but you have to
compare the _right_ text.

Pick up any reference book. A dictionary, a textbook, a phone book, whatever.
Leaf through it a bit. You'll find they all use text formatting to highlight
things. The dictionaries I've used typically use bold for a word and its
different forms, italics for parts of speech, and such. Phone books similarly
use different weights and sizes for names, addresses, and phone numbers.
Textbooks use bold and italics to highlight important terms and concepts and
students will often mark up the books to further highlight certain things.

Code is usually not meant to be read like you would a novel; it's much more
like a reference text. For me, at least, syntax highlighting is a tool that
supports the ability to more easily find what I need and understand it in
isolation. Maybe it would be slower for me to read a syntax-highlighted file
token-by-token end-to-end than an un-highlighted one but that's not a use case
I ever need.

~~~
Philipp__
I have to agree with you on that! My bad that I didn't specify what kind of
text I was refeering to! I thought of example that was provided in the post.

------
jasode
copypaste of my previous comment about this:

I've not found the Alice-in-Wonderland analogy colorizing the "verbs" to be
convincing.

With human language like English, we learn it and use it _without the formal
grammar_ ++. A 5-year old child can speak to her mother ( _" I want some
candy!"_) without conscious knowledge of "verbs" or "nouns". A formal grammar
for categorization is what we _layer on top_ of language for analysis in
school. Two people can communicate and understand each other _without any
exposure to any grammar lessons._ So yes, colorizing verbs looks superfluous
and noisy.[2]

On the other hand, computer programming syntax _starts_ with grammar. You
learn that certain specific tokens are "data types" and other tokens are
"literals", etc, etc. And that grammar categorization in programming languages
_never goes away_ as you're typing out new code. (Otherwise, you'd get a
compiler error or unintended behavior because x="3"+"5" with quotes ("35")
means something different from x=3+5 without quotes (8).) This is why so many
experienced programmers find color highlighting helpful even if they've been
programming that language for 10+ years. Sure we want to focus on higher
cognitive purpose of "semantics" but the grammar is deeply intertwined with
_reconstructing_ what the semantics _is_.

A closer analogy of color highlighting in a different realm would be different
colors in TCPIP traces such as "red" highlighting external ip addresses. This
can be helpful for forensics of malware phoning home.

Or in financials dashboards where uptrends are "green" and downtrends are
"red".

The same reasons that colors help the malware analyst or stock trader quickly
parse data at a glance is also how it helps programmers.

++ (at least not consciously that a 5-year old would be self-aware of it. A
theory of innate universal grammar in the brain by Chomsky isn't what I'm
talking about.)

[2] except for rare examples of using annotation or coloring of verbs to help
parse sentences like this:
[https://en.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffal...](https://en.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffalo_buffalo_buffalo_Buffalo_buffalo)

------
panic
I think there's a middle ground here. Most syntax highlighting uses extremely
saturated clashing colors. The feeling you get for the "texture" of the code
is useful, but it can make the code hard to read all at once. Using a more
toned-down theme brings back some of that legibility without giving up the
benefits of syntax highlighting.

~~~
corysama
I you are using an "Angry Fruit Salad" color scheme, like the example in the
article, it's yer own damn fault for not investing 10 minutes to find
something more sublime.

~~~
figgis
[http://ethanschoonover.com/solarized](http://ethanschoonover.com/solarized)

Best color scheme I have found, I use it for everything. I can't even imagine
opening up some of my code in notepad or vi(m) with no syntax highlighting and
actually trying to do a productive amount of work. This suggestion seems
absolutely ridiculous if your syntax highlighting is sane.

------
jahewson
Taking a guideline for prose and misapplying it to code does not result in a
meaningful insight. Just look at non-prose typeset works such dictionaries, we
often see a selection of different font styles there to help the reader scan
non-linearly. Look also at newspapers, again we see different font styles,
sizes and weights to help the user navigate a page. Look at the references
section of an academic paper - you'll find bold italic and underline all used
on the same line. Color is very expensive to use in printing prose and so is
generally not used, but in handwritten medieval documents color was often
used:

[https://en.m.wikipedia.org/wiki/Rubric](https://en.m.wikipedia.org/wiki/Rubric)

Also this claim isn't even correct - code which varies in color is not
changing typeface! Really it's no different from using bold or italic in
traditional prose, which nobody would complain about.

------
geofft
Every time I have accidentally started my editor without syntax highlighting
due to a misconfiguration (e.g., the file doesn't have the right extension),
it has impeded my understanding.

I will take that _experimental data_ over a pile of arguments from first
principles any day.

~~~
pyre
> _anecdotal data_

Fixed that for you.

~~~
geofft
Why do you think I wrote that incorrectly?

------
nikki-9696
I'll keep it, thanks. My life is far easier with it. You are welcome to use
Notepad.

~~~
bpchaps
Ever use vi/emacs/nano/etc? Pretty sure not everybody who doesn't like syntax
highlighting only uses notepad ;).

~~~
charonn0
Don't vi and emacs support syntax highlighting?

^Ocomment.txt^X

~~~
figgis
vi and emacs certainly support syntax highlighting. Nano does as well.

[http://stackoverflow.com/questions/19444340/how-to-
specify-s...](http://stackoverflow.com/questions/19444340/how-to-specify-
syntax-highlighting-in-vi-editor)

In fact the only text editors that I know of off the top of my head that do
not support syntax highlighting is notepad and pico.

------
hosh
>Developing software is complex and error-prone, so people need to be thinking
when doing it. And yeah, I realize that these opinions are controversial to
some.

I agree. However, I don't see how syntax highlighting necessarily makes
reasoning code easier or harder. I don't know if the arguments are specious,
but I think and feel that much of the arguments in the article are weak and
unconvincing.

The author has already dismissed (without examination) the strongest argument
for syntax highlighting: aesthetics. There are whole philosophies of
aesthetics that makes a lot of sense, but only when we go beyond the mere
results of the programming. The aesthetic argument for syntax highlighting
isn't for the sake of the quality of the resulting program but rather, the
quality of the experience for the programmer. That in and of itself is
underestimated by a fixation on the resulting code.

There are philosophies that precisely define aesthetics, but these are
generally in the non-dual philosophies, not the dualist philosophies. As soon
as you have a dualist philosophy, you set up an opposition between privileging
objective over subjective, or subjective over objective, and it resolves
nothing. Non-dual philosophies do not privilege objective over subjective, or
subjective over objective, and have a lot of useful, testable (empirical,
experienceable) things to say about aesthetics.

Aesthetics bring a human perspective to the technology and reminds us that,
however efficient a technology is, it shapes and is in turn shaped by our
experiences as human beings.

------
akurilin
Definitely iconoclastic, but Linus is also insanely good at what he does, so I
wouldn't be so quick to dismiss that position, there might be something there.

~~~
joemi
But as many others have pointed out, his comparison between code and prose is
completely absurd and shows a complete lack of understanding of what he's
writing about. He's not actually writing about code, he's writing about both
cognitive science and visual design, which I do not believe are his strengths.

------
pbreit
For me syntax highlighting is almost exclusively to reveal my syntax errors
and in that respect is a godsend. This article doesn't resonate with me at
all.

------
jrapdx3
It's pretty common to look at code without highlighting, for example, in code
snippets included with comments here on HN, or printed out on a terminal.
Often it's not too difficult to understand in that circumstance, but it might
well require more effort to grasp vs. syntax highlighted viewing. It suggests
familiarity with the code is a crucial variable in determining the utility of
highlighting or ability to get by without it.

Like others I find highlighting useful for code editing, and agree with the
implication that syntax plays a much bigger role in coding vs. reading non-
code text. IOW semantics of code is obviously far more dependent on syntactic
precision than in ordinary use of language.

Finally, the universality of syntax highlighting in code editors is unlikely
to be due to degenerate comprehension skills among programmers. Rather it's
implicit evidence that highlighting provides substantial productivity benefit
to code writers.

------
1_player
I've always been on the lookout for a very simple syntax theme, very minimal,
while the current trend is have as many colours as possible.

Recently somebody posted microlight.js
([https://asvd.github.io/microlight/](https://asvd.github.io/microlight/))
which has exactly the type of colour theme I'm looking for. Only comments and
strings are highlighted, anything else is the default font.

So I've hacked together in 10 minutes a rough emacs theme, not satisfied yet,
looks like this:
[https://www.dropbox.com/s/p41iw7r5p4dwd4w/Screenshot%202016-...](https://www.dropbox.com/s/p41iw7r5p4dwd4w/Screenshot%202016-06-06%2016.46.48.png?dl=0)

So my questions are:

1) Anyone know a good minimal theme for Emacs?

2) How do I change the emacs font lock for operators/braces? There only seems
to be a hacky way to do it.

~~~
pyre
> while the current trend is have as many colours as possible

Current as opposed to what though? People have always created themes that work
for some people, but not for others. I've even seen themes that used bold,
underline and italics rather than color to "highlight" syntax.

------
femto113
Startled to read this, since I point to syntax highlighting as the single
biggest boost to productivity since I started coding (back in the monochrome
monitor years). Now coding without it feels like trying to play chess with
non-Staunton pieces, there's an extra cognitive load that has nothing to do
with the end goal.

~~~
gingerrr
THIS! I'm shocked to see so few comments discussing the amount of mental
overhead syntax highlighting helps you avoid.

Without syntax highlighting, I have to keep the contextual meaning of every
character I read in state mentally, and constantly update the mental map I
have of the code. I have to actively parse every character.

With syntax highlighting, the relationship of each token to the rest of the
tokens around it is preserved, so that meaning is inferable rather than
needing to be maintained in memory. I can scan and jump around between
meaningful code anchors without having to read every line of code between.
It's like getting to jump straight to the AST.

To each their own, of course. I started programming without syntax
highlighting and the switch made me a faster dev without question.

------
Ultimatt
Most of the time when you "read" code you explicitly want to parse form and
skim over thousands of lines to get a gist of where to drill down. All the
anti arguments on this article almost show a complete inverted understanding
of common requirements.

------
veli_joza
Technical books, dictionaries and similar structured texts consistently use
syntax highlighting. Prose is very different from source code.

Also, it seems to me that the author has bigger problem with the way syntax
highlighting is implemented than the concept itself. I would agree there's
much to be improved in syntax highlighting, in a way that would actually help
programmer and draw attention to problematic constructs. This would require
collaboration between editor and different tools, but it would be a good step
forward I think.

------
bpchaps
I learned to code without any sort of syntax highlighting or autocomplete
features. Whenever I need to use an editor that has Features like syntax
highlighting and autocompletion, my workflow actually slows down pretty
substantially. The negatives just don't beat the positives for me.

Why the negative comments with some folk even calling this guy _wrong_ on an
_opinion_ piece? Sheesh, people..

------
andremendes
I'm honestly considering whether this article is not purposely trying to argue
over a bogus premise only to later warn us to take what we read online with a
grain of salt. I mean, to pose the question "why on earth would people want to
highlighting verbs" as an attempt to prove that syntax highlighting is
unnecessary is not even close to be a good try.

------
draw_down
Semantics are more important than syntax, sure. But it doesn't matter what the
semantics are if you screw up the syntax, which you will be more likely to do
without syntax highlighting because you're a hairless ape.

I just don't see an actual reason not to use it, but if you don't want to,
knock yourself out I guess.

------
dang
Some previous discussions:
[https://hn.algolia.com/?query=A%20case%20against%20syntax%20...](https://hn.algolia.com/?query=A%20case%20against%20syntax%20highlighting&sort=byDate&dateRange=all&type=story&storyText=false&prefix&page=0).

------
Steeeve
You can pry syntax highlighting away from my cold dead body.

The author obviously hasn't spent much time coding.

~~~
khedoros
> The author obviously hasn't spent much time coding.

I take it that you didn't look through his list of projects. There are some
impressive things listed.

------
ebbv
This is such a ridiculous statement I honestly believe it's clickbait and have
flagged it as such.

Syntax highlighting has so many obvious benefits that I think there's only two
types of people who are against it; the first is people who just don't use it
and use it as a silly point of pride that they don't and the second is people
who are just trolling.

While you're typing things get highlighted the correct color indicating your
syntax is correct. For example, you aren't going to forget a quote to end a
string (or start a string) if all your code gets highlighted the wrong color.
This alone is enough to make it worthwhile even if syntax highlighting didn't
do anything else.

I'm not gonna waste a lot of time here listing out the numerous benefits of
syntax highlight but instead make this point; the same dumb argument could be
made against indentation. Why do you need to indent?! You should understand
the code by reading it not based on indentation!

Yeah, that's really stupid isn't it?

------
kdeenanauth
Syntax highlighting for fiction done right(er) -
[http://evanhahn.github.io/English-text-
highlighting/](http://evanhahn.github.io/English-text-highlighting/)

------
scotty79
Douglas Crockford would prefer highlighting that would indicate from which
scope the variable inside the closure comes from.

So specific color for variables in specific scope that carries over to nested
scopes where the variable is used.

------
krabpaaltje
The idea is that syntax highlighting frees up the brain from doing tedious
things like analyzing syntax, to use them on a higher level.

Less strain on the brain, so to speak.

------
enqk
The go creators use the Acme text editor which itself doesn't have syntax
highlighting.

------
huherto
I don't know if it helps me. But it is pretty. I like pretty things.

