Surprising reasons to use a syntax-coloring editor

[Mark-Jason Dominus]

I avoided syntax coloring for years, because it seemed like a pretty
stupid idea, and when I tried it, I didn't see any benefit. But
recently I gave it another try, with Ilya Zakharevich's `cperl-mode'
for Emacs. I discovered that I liked it a lot, but for surprising
reasons that I wasn't expecting.

I'm not trying to start an argument about whether syntax coloring is
good or bad. I've heard those argmuents already and they bore me to
death. Also, I agree with most of the arguments about why syntax
coloring is a bad idea. So I'm not trying to argue one way or the
other; I'm just relating my experiences with syntax coloring. I used
to be someone who didn't like it, but I changed my mind.

When people argue about whether syntax coloring is a good idea or not,
they tend to pull out the same old arguments and dust them off. The
reasons I found for using syntax coloring were new to me; I'd never
seen anyone mention them before. So I thought maybe I'd post them here.

Syntax coloring is when the editor understands something about the
syntax of your program and displays different language constructs in
different fonts. For example, `cperl-mode' displays strings in
reddish brown, comments in a sort of brick color, declared variables
(in `my') in gold, builtin function names (`defined') in green,
subroutine names in blue, labels in teal, and keywords (like `my' and
`foreach') in purple.

The first thing that I noticed about this was that it was easier to
recognize what part of my program I was looking at, because each
screenful of the program had its own color signature. I found that I
was having an easier time remembering where I was or finding that
parts I was looking for when I scrolled around in the file. I wasn't
doing this consciously; I couldn't describe the color scheme any
particular part of the program was, but having red, gold, and purple
blotches all over made is easier to tell parts of the program apart.

The other surprise I got was that I was having more fun programming.
I felt better about my programs, and at the end of the day, I felt
better about the work I had done, just because I'd spent the day
looking at a scoop of rainbow sherbet instead of black and white. It
was just more cheerful to work with varicolored text than monochrome
text. The reason I had never noticed this before was that the other
coloring editors I used had ugly, drab color schemes. Ilya's scheme
won here by using many different hues.

I haven't found many of the other benefits that people say they get
from syntax coloring. For example, I can tell at a glance whether or
not I failed to close a string properly---unless the editor has
screwed up the syntax coloring, which it does often enough to ruin the
benefit for me. And the coloring also slows down the editor. But the
two benefits I've described more than outweigh the drawbacks for me.
Syntax coloring isn't a huge win, but it's definitely a win.

If there's a lesson to learn from this, I guess it's that it can be
valuable to revisit tools that you rejected, to see if you've changed
your mind. Nothing anyone said about it was persuasive to me, but
when I tried it I found that there were reasons to do it that nobody
had mentioned. Of course, these reasons might not be compelling for
anyone else.

I sent followups to comp.programmer.

--

m...@pobox.com Mark-Jason Dominus
m...@plover.com Plover Systems, Philadelphia, PA

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to Mark-Jason Dominus
<m...@plover.com>],
who wrote in article <6l22e8$6ga$1...@picasso.op.net>:

> The other surprise I got was that I was having more fun programming.

Having fun when *writing* Perl is the main reason why I support
CPerl. People very often underestimate the importance of having fun
while programming.

> I felt better about my programs, and at the end of the day, I felt
> better about the work I had done, just because I'd spent the day
> looking at a scoop of rainbow sherbet instead of black and white. It
> was just more cheerful to work with varicolored text than monochrome
> text. The reason I had never noticed this before was that the other
> coloring editors I used had ugly, drab color schemes. Ilya's scheme
> won here by using many different hues.

Well, I hate the standard color scheme. Here is what I use (assuming
you got choose-color.el from my sight):

(setq font-lock-face-attributes
(list
;; Color-light Color-dark Gray-light Gray-dark Mono
(list 'bold
["blue" "yellow" "DimGray" "Gray80"]
nil
t
nil
nil)
(list 'bold-italic
["red" "red" "DimGray" "Gray80"]
nil
t
t
nil)
(list 'italic
["darkorange4" "green" "DimGray" "Gray80"]
nil
nil
t
nil)
(list 'highlight
["red" "red" "DimGray" "Gray80"]
["darkseagreen2" "darkseagreen2" "gray81"]
nil
nil
[nil nil t t])
(list 'region
["red" "red" "DimGray" "Gray80"]
["gray" "grey" "gray90"]
nil
nil
t)
(list 'secondary-selection
["black" "black" "DimGray" "Gray80"]
["paleturquoise" "paleturquoise" "gray81"]
nil
[nil nil t t]
[nil nil t t])
(list 'font-lock-comment-face
["darkorange4" "green" "DimGray" "Gray80"]
nil
[nil nil t t t]
[nil nil t t t]
nil)
(list 'font-lock-string-face
["darkorchid" ("os2white" "white")
"Gray50" "LightGray"]
nil
nil
[nil nil t t t]
[nil nil t])
(list 'font-lock-keyword-face
["blue" "yellow" nil "Gray90"]
nil
[nil nil t t t]
nil
nil)
(list 'font-lock-function-name-face
(vector
"red" "red" nil "LightGray"
(cdr (assq 'background-color ; if mono
(frame-parameters))))
(vector
nil nil nil nil
(cdr (assq 'foreground-color ; if mono
(frame-parameters))))
[nil nil t t t]
[nil nil t t]
nil)
(list 'font-lock-variable-name-face
["DarkGoldenrod" "LightGoldenrod" "DimGray" "Gray90"]
nil
[nil nil t t t]
[nil nil t t t]
nil)
(list 'font-lock-type-face
["seagreen" ("os2pink" "pink")
nil "Gray80"]
[nil nil "gray90"]
[nil nil nil t t]
nil
[nil nil t t t]
)
(list 'font-lock-other-type-face
["chartreuse3" ("orchid1" "orange")
nil "Gray80"]
[nil nil "gray90"]
[nil nil nil t t]
[nil nil t t]
[nil nil t t t]
)
(list 'font-lock-emphasized-face
["blue" "yellow" nil "Gray80"]
["lightyellow2" ("navy" "os2blue" "darkgreen")
"gray90"]
t
nil
nil)
(list 'font-lock-other-emphasized-face
["red" "red" nil "Gray80"]
["lightyellow2" ("navy" "os2blue" "darkgreen")
"gray90"]
t
t
nil)
(list 'font-lock-reference-face
["orange" "dodgerblue1" "Gray50" "LightGray"]
nil
[nil nil t t t]
nil
[nil nil t t t]
)
(list 'lazy-lock-invisible-face
["DarkGoldenrod" "LightGoldenrod" "DimGray" "Gray90"]
nil
nil
nil
nil)
))

> I haven't found many of the other benefits that people say they get
> from syntax coloring. For example, I can tell at a glance whether or
> not I failed to close a string properly---unless the editor has
> screwed up the syntax coloring, which it does often enough to ruin the
> benefit for me.

A couple of days ago I finally fixed CPerl that it does
resyntaxification on the fly (I may release it as v3.5 in a couple of
days). And guess what I discover yesterday?

Emacs 20.2.94 has *completely* screwed-up syntax-assist code... Thus
syntax-assist which CPerl is using on newer Emaxen is completely
useless.

So far the best environment to run CPerl is 20.2 with 2 patches from
my site.

Ilya

[Chris Nandor]

In article <6l22e8$6ga$1...@picasso.op.net>, m...@plover.com (Mark-Jason
Dominus) wrote:

# The first thing that I noticed about this was that it was easier to
# recognize what part of my program I was looking at, because each
# screenful of the program had its own color signature. I found that I
# was having an easier time remembering where I was or finding that
# parts I was looking for when I scrolled around in the file. I wasn't
# doing this consciously; I couldn't describe the color scheme any
# particular part of the program was, but having red, gold, and purple
# blotches all over made is easier to tell parts of the program apart.
#
# The other surprise I got was that I was having more fun programming.
# I felt better about my programs, and at the end of the day, I felt
# better about the work I had done, just because I'd spent the day
# looking at a scoop of rainbow sherbet instead of black and white. It
# was just more cheerful to work with varicolored text than monochrome
# text. The reason I had never noticed this before was that the other
# coloring editors I used had ugly, drab color schemes. Ilya's scheme
# won here by using many different hues.

Interesting. I have noticed similar things as well. Just scrolling
through I can easily pick up patterns, but I never reall thought about
it. But I *have* consciously recognized that I simply LIKE LOOKING at the
code more when it is colored nicely.

--
Chris Nandor mailto:pu...@pobox.com http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])

[resslere]

Agree with all your points, tho I do occasionally save some time with
comment coloring in C, pascal, and other languages that allow multi-line
comments. Something like this...

/* Initialize factorial result *
fact = 1;

/* Compute fact(n) */
for (i = 2; i <= n; i++)
fact *= i;

gets hard to see at the end of the day!

Anyway, I know folks that love to print their code with pretty printers for
the same kinds of reasons. It's somehow satisfying to see code typeset
nicely, even though having the code on paper is just about useless.

Gene

+
Mark-Jason Dominus <m...@plover.com> wrote in article
<6l22e8$6ga$1...@picasso.op.net>...

[Chris Nandor]

In article <01bd8f79$9728f320$fe34accf@zen>, "resslere"
<ress...@erols.com> wrote:

# It's somehow satisfying to see code typeset
# nicely, even though having the code on paper is just about useless.

Unless you forget to back up and your drive crashes ... ;-)