Emacs Flaw: Lisp Mode Syntax Coloring
This page gives discuss a problem of emacs's “emacs-lisp-mode”'s syntax coloring.
Emacs has a mode for editing emacs lisp code. The mode is called
emacs-lisp-mode
. However, the syntax highlighting in emacs-lisp-mode
only color very few emacs lisp keywords.
For example:
- Colored:
defun
lambda
while
if
progn
save-restriction
- Uncolored:
interactive
or
and
setq
goto-char
mapc
point-min
search-forward
car
nil
replace-match
narrow-to-region
Here's a example of elisp source code colored by emacs-lisp-mode
:

Here's a desired coloring:

In many language modes, all the language's keywords are syntax colored.
They are colored differently according to the keyword's role (e.g. {function, class, object, type, operator, etc}).
If you don't like so many colors, you can set font-lock-maximum-decoration to 1, 2, or 3, for progressively more colors.
However, in emacs-lisp-mode, only a subset of keywords are colored, and emacs-lisp-mode doesn't support customize-group
, nor levels for font-lock-maximum-decoration.
So, you are stuck with the most basic coloring of a subset of keywords.
It is suggested that the mode only color a special class of elisp symbols called “special forms” (see:
What Is a Function (ELISP Manual)
).
However, that is not true. or
is a special form, but is not colored.
I think the symbols chosen to color is heuristic based for the goal of ease-of-reading. Namely, keywords that are likely to be significant and starting a code block are colored.
example:
let
lambda
if
unless
while
progn
cond
condition-case
save-excursion
with-current-buffer
with-selected-window
with-output-to-temp-buffer
with-selected-window
, and few more.
However, the coloring scheme is unpredictable, inconsistent, and difficult to understand.
If emacs-lisp-mode colors all built-in symbols by their semantics class (e.g. function, command, variable, macro, special form …), with support for levels of font-lock, the advantage of highlighting only significant keyword can be maintained, while making it more systematic, understandable, and flexible.
This report applies to at least GNU Emacs 22.2 to GNU Emacs 24.3.1
This essay is originally posted to gnu.emacs.help newsgroup. I filed this as emacs bug report, debbugs.gnu.org #2630

Fix: Xah Emacs Lisp Mode
2013-05-04 I started to build a mode to fix this. See: Emacs: Xah Elisp Mode 📦