GNU bug report logs - #79623
30.1; c-ts-mode wrong face for variable assignments

Previous Next

To reply to this bug, email your comments to 79623 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Robert Brown <robert.brown <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.1; c-ts-mode wrong face for variable assignments
Date: Tue, 14 Oct 2025 10:41:29 -0400

[Message part 1 (text/plain, inline)]

When editing a C source file using c-ts-mode, variable assignments are
fontified using font-lock-variable-name-face instead of
font-lock-variable-use-face.  The following patch should fix the
problem.

diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el
index 174eb47cb3a..006575d7586 100644
--- a/lisp/progmodes/c-ts-mode.el
+++ b/lisp/progmodes/c-ts-mode.el
@@ -827,15 +827,15 @@ c-ts-mode--font-lock-settings
    ;; expressions, see `c-ts-mode--fontify-declarator' for
    ;; inspiration.
    '((assignment_expression
-      left: (identifier) @font-lock-variable-name-face)
+      left: (identifier) @font-lock-variable-use-face)
      (assignment_expression
       left: (field_expression field: (_) @font-lock-property-use-face))
      (assignment_expression
       left: (pointer_expression
-             (identifier) @font-lock-variable-name-face))
+             (identifier) @font-lock-variable-use-face))
      (assignment_expression
       left: (subscript_expression
-             (identifier) @font-lock-variable-name-face))
+             (identifier) @font-lock-variable-use-face))
      (init_declarator declarator: (_) @c-ts-mode--fontify-declarator))

    :feature 'function



In GNU Emacs 30.1 (build 4, x86_64-pc-linux-gnu) of 2025-02-23 built on
 chuwi
System Description: Ubuntu 24.04.3 LTS

Configured using:
 'configure --without-x
 --prefix=/home/brown/local/software/package/emacs-30.1'

Configured features:
DBUS GMP GNUTLS LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER SECCOMP SOUND THREADS TREE_SITTER XIM ZLIB

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Apropos

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  line-number-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/brown/local/software/source/slime/slime-tests hides
/home/brown/.emacs.d/elpa/slime-20240323.141/slime-tests
/home/brown/local/software/source/slime/slime-autoloads hides
/home/brown/.emacs.d/elpa/slime-20240323.141/slime-autoloads
/home/brown/local/software/source/slime/slime hides
/home/brown/.emacs.d/elpa/slime-20240323.141/slime
/home/brown/lib/emacs/lisp/yow hides
/home/brown/local/software/package/emacs-30.1/share/emacs/30.1/lisp/obsolete/yow

Features:
(shadow sort mail-extr cl-extra warnings compile comint ansi-osc
ansi-color comp-run comp-common emacsbug message yank-media puny dired
dnd dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util text-property-search time-date mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils misearch multi-isearch
mule-util help-mode apropos term/xterm xterm company-oddmuse
company-keywords company-etags etags fileloop generator xref project
ring company-gtags company-dabbrev-code company-dabbrev company-files
company-clang company-capf company-cmake company-semantic
company-template company-bbdb company pcase cc-styles cc-align cc-engine
cc-vars cc-defs regexp-opt rx dash-autoloads ement-autoloads
persist-autoloads plz-autoloads slime-company-autoloads slime-autoloads
macrostep-autoloads svg-lib-autoloads taxy-magit-section-autoloads
taxy-autoloads info tool-bar magit-section-autoloads llama-autoloads
package browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie generate-lisp-file url-domsuf url-util mailcap
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs icons
password-cache json subr-x map byte-opt gv bytecomp byte-compile
url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select mouse
jit-lock font-lock syntax font-core term/tty-colors frame minibuffer
nadvice seq simple cl-generic indonesian philippine cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop
case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify multi-tty make-network-process native-compile
emacs)

Memory information:
((conses 16 147863 128982) (symbols 48 11756 49) (strings 32 38286 13825)
 (string-bytes 1 1287124) (vectors 16 16420) (vector-slots 8 195936 52605)
 (floats 8 72 31) (intervals 56 550 147) (buffers 992 13))

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Brown <robert.brown <at> gmail.com>,
 Yuan Fu <casouri <at> gmail.com>
Cc: 79623 <at> debbugs.gnu.org
Subject: Re: bug#79623: 30.1; c-ts-mode wrong face for variable assignments
Date: Tue, 14 Oct 2025 18:53:33 +0300

> From: Robert Brown <robert.brown <at> gmail.com>
> Date: Tue, 14 Oct 2025 10:41:29 -0400
> 
> When editing a C source file using c-ts-mode, variable assignments are
> fontified using font-lock-variable-name-face instead of
> font-lock-variable-use-face.  The following patch should fix the
> problem.

Thanks, but I'm not sure this is correct.  For starters, c-mode
doesn't use that face at all, it only uses
font-lock-variable-name-face.

And what about this case:

  int foo = bar;

> diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el
> index 174eb47cb3a..006575d7586 100644
> --- a/lisp/progmodes/c-ts-mode.el
> +++ b/lisp/progmodes/c-ts-mode.el
> @@ -827,15 +827,15 @@ c-ts-mode--font-lock-settings
>     ;; expressions, see `c-ts-mode--fontify-declarator' for
>     ;; inspiration.
>     '((assignment_expression
> -      left: (identifier) @font-lock-variable-name-face)
> +      left: (identifier) @font-lock-variable-use-face)
>       (assignment_expression
>        left: (field_expression field: (_) @font-lock-property-use-face))
>       (assignment_expression
>        left: (pointer_expression
> -             (identifier) @font-lock-variable-name-face))
> +             (identifier) @font-lock-variable-use-face))
>       (assignment_expression
>        left: (subscript_expression
> -             (identifier) @font-lock-variable-name-face))
> +             (identifier) @font-lock-variable-use-face))
>       (init_declarator declarator: (_) @c-ts-mode--fontify-declarator))
>  
>     :feature 'function

Yuan, WDYT?

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

From: Robert Brown <robert.brown <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79623 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com>
Subject: Re: bug#79623: 30.1; c-ts-mode wrong face for variable assignments
Date: Tue, 14 Oct 2025 12:50:33 -0400

[Message part 1 (text/plain, inline)]

c-mode only uses font-lock-variable-name-face.  Uses of variables are
fontified with the default face.  That's actually the behavior I prefer.
So with the statements

    int foo = bar;
    baz = 100;

c-mode fontifies foo using font-lock-variable-name-face but bar and baz are
rendered using the default face.  Traditionally,
font-lock-variable-name-face has only been used to highlight variables
where they are defined.

c-ts-mode differs from c-mode in that it fontifies baz but not bar using
font-lock-variable-name-face.  Instead, it should use
font-lock-variable-use-face, ideally for both bar and baz.  That allows me
to duplicate the behavior of c-mode in c-ts-mode by overriding the default
definition of font-lock-variable-use-face, setting it to be the default
face.  Alternatively, cs-ts-mode could stop fontifying baz using
font-lock-variable-name-face.


On Tue, Oct 14, 2025 at 11:53 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Robert Brown <robert.brown <at> gmail.com>
> > Date: Tue, 14 Oct 2025 10:41:29 -0400
> >
> > When editing a C source file using c-ts-mode, variable assignments are
> > fontified using font-lock-variable-name-face instead of
> > font-lock-variable-use-face.  The following patch should fix the
> > problem.
>
> Thanks, but I'm not sure this is correct.  For starters, c-mode
> doesn't use that face at all, it only uses
> font-lock-variable-name-face.
>
> And what about this case:
>
>   int foo = bar;
>
> > diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el
> > index 174eb47cb3a..006575d7586 100644
> > --- a/lisp/progmodes/c-ts-mode.el
> > +++ b/lisp/progmodes/c-ts-mode.el
> > @@ -827,15 +827,15 @@ c-ts-mode--font-lock-settings
> >     ;; expressions, see `c-ts-mode--fontify-declarator' for
> >     ;; inspiration.
> >     '((assignment_expression
> > -      left: (identifier) @font-lock-variable-name-face)
> > +      left: (identifier) @font-lock-variable-use-face)
> >       (assignment_expression
> >        left: (field_expression field: (_) @font-lock-property-use-face))
> >       (assignment_expression
> >        left: (pointer_expression
> > -             (identifier) @font-lock-variable-name-face))
> > +             (identifier) @font-lock-variable-use-face))
> >       (assignment_expression
> >        left: (subscript_expression
> > -             (identifier) @font-lock-variable-name-face))
> > +             (identifier) @font-lock-variable-use-face))
> >       (init_declarator declarator: (_) @c-ts-mode--fontify-declarator))
> >
> >     :feature 'function
>
> Yuan, WDYT?
>

[Message part 2 (text/html, inline)]

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

From: Yuan Fu <casouri <at> gmail.com>
To: Robert Brown <robert.brown <at> gmail.com>
Cc: 79623 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79623: 30.1; c-ts-mode wrong face for variable assignments
Date: Thu, 23 Oct 2025 23:27:31 -0700

> On Oct 14, 2025, at 9:50 AM, Robert Brown <robert.brown <at> gmail.com> wrote:
> 
> c-mode only uses font-lock-variable-name-face.  Uses of variables are fontified with the default face.  That's actually the behavior I prefer.  So with the statements
> 
>     int foo = bar;
>     baz = 100;
> 
> c-mode fontifies foo using font-lock-variable-name-face but bar and baz are rendered using the default face.  Traditionally, font-lock-variable-name-face has only been used to highlight variables where they are defined.

> c-ts-mode differs from c-mode in that it fontifies baz but not bar using font-lock-variable-name-face.  Instead, it should use font-lock-variable-use-face, ideally for both bar and baz.  That allows me to duplicate the behavior of c-mode in c-ts-mode by overriding the default definition of font-lock-variable-use-face, setting it to be the default face.  Alternatively, cs-ts-mode could stop fontifying baz using font-lock-variable-name-face.

When the difference is subjective, I have no problem making c-ts-mode follow c-mode’s fontification. But still, using different faces for LHS and RHS of an assignment makes more sense to me, since they have distinct connotations. So I’ll make it configurable to either use variable-name-face or variable-use-face for the LHS. Or should I instead allow user to choose whether to fontify the LHS variable? Hmm...

Yuan

Previous Next

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