Emacs Lisp Mode Syntax Coloring Problem
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 (For example, {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 (For example, 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 (xah-elisp-mode.el)
Emacs Modernization
- Emacs Modernization: Simple Changes Emacs Should Adopt
- Why Emacs Keys are Painful
- Emacs: Problems of the Scratch Buffer
- Emacs M-key Notation vs Alt+key Notation
- Emacs Menu Usability Problem
- Emacs Mode Line Problem
- Emacs cua-mode Problems
- Emacs: Inconsistency of Search Features
- Problems of grep in Emacs
- Emacs: Usability Problems of Mode Documentation
- Problems of Emacs Manual
- Emacs Manual Sucks by Examples
- Emacs: kill-buffer Induces Buffer Accumulation
- Emacs Spell Checker Problems
- Emacs Form Feed ^L Problems
- Emacs: Single Key to Delete Whole Line
- Emacs HTML Mode Sucks
- Emacs Does Not Support Viewing Images Files In Windows
- Emacs Should Adopt HTML as Texinfo Replacement
- Emacs Should Support HTML Mail
- Problems of Emacs's “man” Command
- Emacs Lisp Mode Syntax Coloring Problem
- Emacs AutoHotkey Mode Problems
- Emacs Lisp: Ban Syntax Table
- Emacs: Make elisp-index-search use Current Symbol
- Emacs GNU Texinfo Problems; Invalid HTML
- A Record of Frustration in IT Industry; Disappearing FSF URLs, 2006
- Emacs Manual Node Persistency Issues
- Emacs: dired-do-query-replace-regex Replace ALL (fixed)
- Problems of Emacs Supporting Obsolete Systems
- Emacs Lisp: Function to Copy/Delete a Dir Recursively (fixed)
- Thoughts on Common Lisp Scheme Lisp Based Emacs
- Text Editors Popularity and Market Research
- Text Editor's Cursor Movement Behavior (emacs, vi, Notepad++)
- Emacs: Toggle Letter Case 🚀
- Emacs: Select Line, between Quotes, Extend Selection 🚀
- Emacs: isearch Current Word 🚀
- Emacs fill-paragraph Problem