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, …}). 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: (info "(elisp) What Is a Function")). 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
Emacs Modernization
- Simple Changes Emacs Should Adopt
- Why Emacs Keys are Painful
- Ban Scratch Buffer
- M-x vs Alt+x Notation
- Menu Idiocy
- Mode Line Problem
- cua-mode Problem
- Inconsistency of Search
- grep in emacs Pain
- Problems of describe-mode
- Problems of Emacs Manual
- Emacs Manual Sucks by Examples
- kill-buffer Problem
- Emacs Spell Checker Pain
- Form Feed ^L
- Single Key Delete Whole Line
- Emacs HTML Mode Sucks
- Emacs No View Image on Windows
- HTML should replace Texinfo
- Support HTML Mail
- Problems of “man”
- Emacs Lisp Mode Syntax Coloring Problem
- Emacs AHK Mode Problems
- Ban Syntax Table
- Make elisp-index-search use Current Symbol
- Texinfo Invalid HTML
- Disappearing FSF URLs, 2006
- Emacs Manual Node Persistency Issues
- Emacs: dired-do-query-replace-regex Replace ALL (fixed)
- Problems of Emacs Supporting Obsolete Systems
- Elisp: Function to Copy/Delete a Dir Recursively (fixed)
- CommonLisp/SchemeLisp Emacs
- Text Editors Popularity
- Cursor Movement Behavior Survey
- Letter-Case Commands Problem
- Select Line/Block/Quote, Extend
- isearch Current Word
- Reformat Line Wrap