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