GNU bug report logs - #51574
27.2; Bad Lisp font-locking with `font-lock-type-face'

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 27.2; Bad Lisp font-locking with `font-lock-type-face'
Date: Tue, 2 Nov 2021 22:28:41 +0000

This regression was introduced in Emacs 25 (no problem before then).

emacs -Q

In buffer *scratch* type this Lisp code:

(car `(foo\ &bar toto))
(car `(foo\&bar toto))
(car `(foo&bar toto))

The first sexp evaluates to the symbol `foo &bar'.  The second and third
evaluate to the symbol `foo&bar'.  The first `\' escapes the SPC char.
The second `\' does nothing (a noop) - it escapes a char that doesn't
need escaping for it to be included in a Lisp symbol name.

But Emacs Lisp font-locking incorrectly gives the `&bar' part of each of
those symbols the face `font-lock-type-face'.  It doesn't correctly
recognize symbol syntax.

There should be no reason to determine that `&bar' represents part of a
type or class name, in any such context.

The bug is in variable `lisp-el-font-lock-keywords-2'.

BTW, the doc string of face `font-lock-type-face' should also be fixed,
to say either "type and class" or "types and classes", not this:

  Font Lock mode face used to highlight type and classes.

In GNU Emacs 27.2 (build 1, x86_64-w64-mingw32)
 of 2021-03-26 built on CIRROCUMULUS
Repository revision: deef5efafb70f4b171265b896505b92b6eef24e6
Repository branch: HEAD
Windowing system distributor 'Microsoft Corp.', version 10.0.19042
System Description: Microsoft Windows 10 Pro (v10.0.2009.19042.1288)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.