GNU logs - #79623, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#79623: 30.1; c-ts-mode wrong face for variable assignments
Resent-From: Robert Brown <robert.brown@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 14 Oct 2025 14:43:03 +0000
Resent-Message-ID: <handler.79623.B.176045292813426 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 79623 <at> debbugs.gnu.org
MIME-Version: 1.0
From: Robert Brown <robert.brown@HIDDEN>
Date: Tue, 14 Oct 2025 10:41:29 -0400
Message-ID: <CAPNkkpnvn4D=wwbvSnLhh0qH3GZfAVb1bijnsE-UKkPwpXGgKw@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000d023e606411f6115"
Received-SPF: pass client-ip=2607:f8b0:4864:20::52a;
 envelope-from=robert.brown@HIDDEN; helo=mail-pg1-x52a.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

--000000000000d023e606411f6115
Content-Type: text/plain; charset="UTF-8"

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))

--000000000000d023e606411f6115
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">When editing a C source file using c-ts-mode, variable ass=
ignments are<br>fontified using font-lock-variable-name-face instead of<br>=
font-lock-variable-use-face.=C2=A0 The following patch should fix the<br>pr=
oblem.<br><br>diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-t=
s-mode.el<br>index 174eb47cb3a..006575d7586 100644<br>--- a/lisp/progmodes/=
c-ts-mode.el<br>+++ b/lisp/progmodes/c-ts-mode.el<br>@@ -827,15 +827,15 @@ =
c-ts-mode--font-lock-settings<br>=C2=A0 =C2=A0 ;; expressions, see `c-ts-mo=
de--fontify-declarator&#39; for<br>=C2=A0 =C2=A0 ;; inspiration.<br>=C2=A0 =
=C2=A0 &#39;((assignment_expression<br>- =C2=A0 =C2=A0 =C2=A0left: (identif=
ier) @font-lock-variable-name-face)<br>+ =C2=A0 =C2=A0 =C2=A0left: (identif=
ier) @font-lock-variable-use-face)<br>=C2=A0 =C2=A0 =C2=A0 (assignment_expr=
ession<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0left: (field_expression field: (_) @fo=
nt-lock-property-use-face))<br>=C2=A0 =C2=A0 =C2=A0 (assignment_expression<=
br>=C2=A0 =C2=A0 =C2=A0 =C2=A0left: (pointer_expression<br>- =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (identifier) @font-lock-variable-name-face))<br=
>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (identifier) @font-lock-variab=
le-use-face))<br>=C2=A0 =C2=A0 =C2=A0 (assignment_expression<br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0left: (subscript_expression<br>- =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 (identifier) @font-lock-variable-name-face))<br>+ =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (identifier) @font-lock-variable-use-fac=
e))<br>=C2=A0 =C2=A0 =C2=A0 (init_declarator declarator: (_) @c-ts-mode--fo=
ntify-declarator))<br>=C2=A0<br>=C2=A0 =C2=A0 :feature &#39;function<br><br=
><br><br>In GNU Emacs 30.1 (build 4, x86_64-pc-linux-gnu) of 2025-02-23 bui=
lt on<br>=C2=A0chuwi<br>System Description: Ubuntu 24.04.3 LTS<br><br>Confi=
gured using:<br>=C2=A0&#39;configure --without-x<br>=C2=A0--prefix=3D/home/=
brown/local/software/package/emacs-30.1&#39;<br><br>Configured features:<br=
>DBUS GMP GNUTLS LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY<b=
r>INOTIFY PDUMPER SECCOMP SOUND THREADS TREE_SITTER XIM ZLIB<br><br>Importa=
nt settings:<br>=C2=A0 value of $LC_COLLATE: C<br>=C2=A0 value of $LANG: en=
_US.UTF-8<br>=C2=A0 value of $XMODIFIERS: @im=3Dibus<br>=C2=A0 locale-codin=
g-system: utf-8-unix<br><br>Major mode: Apropos<br><br>Minor modes in effec=
t:<br>=C2=A0 tooltip-mode: t<br>=C2=A0 global-eldoc-mode: t<br>=C2=A0 show-=
paren-mode: t<br>=C2=A0 file-name-shadow-mode: t<br>=C2=A0 global-font-lock=
-mode: t<br>=C2=A0 font-lock-mode: t<br>=C2=A0 blink-cursor-mode: t<br>=C2=
=A0 minibuffer-regexp-mode: t<br>=C2=A0 buffer-read-only: t<br>=C2=A0 line-=
number-mode: t<br>=C2=A0 auto-composition-mode: t<br>=C2=A0 auto-encryption=
-mode: t<br>=C2=A0 auto-compression-mode: t<br><br>Load-path shadows:<br>/h=
ome/brown/local/software/source/slime/slime-tests hides /home/brown/.emacs.=
d/elpa/slime-20240323.141/slime-tests<br>/home/brown/local/software/source/=
slime/slime-autoloads hides /home/brown/.emacs.d/elpa/slime-20240323.141/sl=
ime-autoloads<br>/home/brown/local/software/source/slime/slime hides /home/=
brown/.emacs.d/elpa/slime-20240323.141/slime<br>/home/brown/lib/emacs/lisp/=
yow hides /home/brown/local/software/package/emacs-30.1/share/emacs/30.1/li=
sp/obsolete/yow<br><br>Features:<br>(shadow sort mail-extr cl-extra warning=
s compile comint ansi-osc<br>ansi-color comp-run comp-common emacsbug messa=
ge yank-media puny dired<br>dnd dired-loaddefs rfc822 mml mml-sec epa deriv=
ed epg rfc6068 epg-config<br>gnus-util text-property-search time-date mm-de=
code mm-bodies mm-encode<br>mail-parse rfc2231 mailabbrev gmm-utils mailhea=
der sendmail rfc2047<br>rfc2045 ietf-drums mm-util mail-prsvr mail-utils mi=
search multi-isearch<br>mule-util help-mode apropos term/xterm xterm compan=
y-oddmuse<br>company-keywords company-etags etags fileloop generator xref p=
roject<br>ring company-gtags company-dabbrev-code company-dabbrev company-f=
iles<br>company-clang company-capf company-cmake company-semantic<br>compan=
y-template company-bbdb company pcase cc-styles cc-align cc-engine<br>cc-va=
rs cc-defs regexp-opt rx dash-autoloads ement-autoloads<br>persist-autoload=
s plz-autoloads slime-company-autoloads slime-autoloads<br>macrostep-autolo=
ads svg-lib-autoloads taxy-magit-section-autoloads<br>taxy-autoloads info t=
ool-bar magit-section-autoloads llama-autoloads<br>package browse-url url u=
rl-proxy url-privacy url-expand url-methods<br>url-history url-cookie gener=
ate-lisp-file url-domsuf url-util mailcap<br>url-handlers url-parse auth-so=
urce cl-seq eieio eieio-core cl-macs icons<br>password-cache json subr-x ma=
p byte-opt gv bytecomp byte-compile<br>url-vars cl-loaddefs cl-lib rmc iso-=
transl tooltip cconv eldoc paren<br>electric uniquify ediff-hook vc-hooks l=
isp-float-type elisp-mode<br>tabulated-list replace newcomment text-mode li=
sp-mode prog-mode register<br>page tab-bar menu-bar rfn-eshadow isearch eas=
ymenu timer select mouse<br>jit-lock font-lock syntax font-core term/tty-co=
lors frame minibuffer<br>nadvice seq simple cl-generic indonesian philippin=
e cham georgian<br>utf-8-lang misc-lang vietnamese tibetan thai tai-viet la=
o korean<br>japanese eucjp-ms cp51932 hebrew greek romanian slovak czech eu=
ropean<br>ethiopic indian cyrillic chinese composite emoji-zwj charscript c=
harprop<br>case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure<b=
r>cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp<br>fi=
les window text-properties overlay sha1 md5 base64 format env<br>code-pages=
 mule custom widget keymap hashtable-print-readable backquote<br>threads db=
usbind inotify multi-tty make-network-process native-compile<br>emacs)<br><=
br>Memory information:<br>((conses 16 147863 128982) (symbols 48 11756 49) =
(strings 32 38286 13825)<br>=C2=A0(string-bytes 1 1287124) (vectors 16 1642=
0) (vector-slots 8 195936 52605)<br>=C2=A0(floats 8 72 31) (intervals 56 55=
0 147) (buffers 992 13))<br><br></div>

--000000000000d023e606411f6115--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Robert Brown <robert.brown@HIDDEN>
Subject: bug#79623: Acknowledgement (30.1; c-ts-mode wrong face for
 variable assignments)
Message-ID: <handler.79623.B.176045292813426.ack <at> debbugs.gnu.org>
References: <CAPNkkpnvn4D=wwbvSnLhh0qH3GZfAVb1bijnsE-UKkPwpXGgKw@HIDDEN>
X-Gnu-PR-Message: ack 79623
X-Gnu-PR-Package: emacs
Reply-To: 79623 <at> debbugs.gnu.org
Date: Tue, 14 Oct 2025 14:43:04 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 79623 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
79623: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D79623
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#79623: 30.1; c-ts-mode wrong face for variable assignments
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 14 Oct 2025 15:54:02 +0000
Resent-Message-ID: <handler.79623.B79623.176045722432735 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Robert Brown <robert.brown@HIDDEN>, Yuan Fu <casouri@HIDDEN>
Cc: 79623 <at> debbugs.gnu.org
Date: Tue, 14 Oct 2025 18:53:33 +0300
Message-Id: <86a51t32f6.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <CAPNkkpnvn4D=wwbvSnLhh0qH3GZfAVb1bijnsE-UKkPwpXGgKw@HIDDEN>
 (message from Robert Brown on Tue, 14 Oct 2025 10:41:29 -0400)
References: <CAPNkkpnvn4D=wwbvSnLhh0qH3GZfAVb1bijnsE-UKkPwpXGgKw@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> From: Robert Brown <robert.brown@HIDDEN>
> 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 sent to bug-gnu-emacs@HIDDEN:

Subject: bug#79623: 30.1; c-ts-mode wrong face for variable assignments
Resent-From: Robert Brown <robert.brown@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 14 Oct 2025 16:51:01 +0000
Resent-Message-ID: <handler.79623.B79623.176046065727777 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 79623 <at> debbugs.gnu.org, Yuan Fu <casouri@HIDDEN>
MIME-Version: 1.0
References: <CAPNkkpnvn4D=wwbvSnLhh0qH3GZfAVb1bijnsE-UKkPwpXGgKw@HIDDEN>
 <86a51t32f6.fsf@HIDDEN>
In-Reply-To: <86a51t32f6.fsf@HIDDEN>
From: Robert Brown <robert.brown@HIDDEN>
Date: Tue, 14 Oct 2025 12:50:33 -0400
Message-ID: <CAPNkkpmWEqSdesj6Q+B9xTpMYjL5frXgHmJLveREMGtXKDAwhg@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000007616a10641212f00"
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--0000000000007616a10641212f00
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 =3D bar;
    baz =3D 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=E2=80=AFAM Eli Zaretskii <eliz@HIDDEN> wrote=
:

> > From: Robert Brown <robert.brown@HIDDEN>
> > 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 =3D 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?
>

--0000000000007616a10641212f00
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">c-mode only uses font-lock-variable-name-face.=C2=A0 Uses =
of variables are fontified with the default face.=C2=A0 That&#39;s actually=
 the behavior I prefer.=C2=A0 So with the statements<div><div><br></div><di=
v>=C2=A0 =C2=A0 int foo =3D bar;</div><div>=C2=A0 =C2=A0 baz =3D 100;</div>=
<div><br></div><div>c-mode fontifies foo using font-lock-variable-name-face=
 but bar and baz are rendered using the default face.=C2=A0 Traditionally, =
font-lock-variable-name-face has only been used to highlight variables wher=
e they are defined.</div><div><br></div><div>c-ts-mode differs from c-mode =
in that it fontifies baz but not bar using font-lock-variable-name-face.=C2=
=A0 Instead, it should use font-lock-variable-use-face, ideally for both ba=
r and baz.=C2=A0 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.=C2=A0 Alternatively, cs-ts-mode could st=
op fontifying baz using font-lock-variable-name-face.</div><div><br></div><=
/div></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D=
"ltr" class=3D"gmail_attr">On Tue, Oct 14, 2025 at 11:53=E2=80=AFAM Eli Zar=
etskii &lt;<a href=3D"mailto:eliz@HIDDEN">eliz@HIDDEN</a>&gt; wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">&gt; From: Robert Br=
own &lt;<a href=3D"mailto:robert.brown@HIDDEN" target=3D"_blank">robert.=
brown@HIDDEN</a>&gt;<br>
&gt; Date: Tue, 14 Oct 2025 10:41:29 -0400<br>
&gt; <br>
&gt; When editing a C source file using c-ts-mode, variable assignments are=
<br>
&gt; fontified using font-lock-variable-name-face instead of<br>
&gt; font-lock-variable-use-face.=C2=A0 The following patch should fix the<=
br>
&gt; problem.<br>
<br>
Thanks, but I&#39;m not sure this is correct.=C2=A0 For starters, c-mode<br=
>
doesn&#39;t use that face at all, it only uses<br>
font-lock-variable-name-face.<br>
<br>
And what about this case:<br>
<br>
=C2=A0 int foo =3D bar;<br>
<br>
&gt; diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el=
<br>
&gt; index 174eb47cb3a..006575d7586 100644<br>
&gt; --- a/lisp/progmodes/c-ts-mode.el<br>
&gt; +++ b/lisp/progmodes/c-ts-mode.el<br>
&gt; @@ -827,15 +827,15 @@ c-ts-mode--font-lock-settings<br>
&gt;=C2=A0 =C2=A0 =C2=A0;; expressions, see `c-ts-mode--fontify-declarator&=
#39; for<br>
&gt;=C2=A0 =C2=A0 =C2=A0;; inspiration.<br>
&gt;=C2=A0 =C2=A0 =C2=A0&#39;((assignment_expression<br>
&gt; -=C2=A0 =C2=A0 =C2=A0 left: (identifier) @font-lock-variable-name-face=
)<br>
&gt; +=C2=A0 =C2=A0 =C2=A0 left: (identifier) @font-lock-variable-use-face)=
<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0(assignment_expression<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 left: (field_expression field: (_) @font-lo=
ck-property-use-face))<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0(assignment_expression<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 left: (pointer_expression<br>
&gt; -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(identifier) @font-lo=
ck-variable-name-face))<br>
&gt; +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(identifier) @font-lo=
ck-variable-use-face))<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0(assignment_expression<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 left: (subscript_expression<br>
&gt; -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(identifier) @font-lo=
ck-variable-name-face))<br>
&gt; +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(identifier) @font-lo=
ck-variable-use-face))<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0(init_declarator declarator: (_) @c-ts-mode-=
-fontify-declarator))<br>
&gt;=C2=A0 <br>
&gt;=C2=A0 =C2=A0 =C2=A0:feature &#39;function<br>
<br>
Yuan, WDYT?<br>
</blockquote></div>

--0000000000007616a10641212f00--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#79623: 30.1; c-ts-mode wrong face for variable assignments
Resent-From: Yuan Fu <casouri@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 24 Oct 2025 06:28:02 +0000
Resent-Message-ID: <handler.79623.B79623.176128727214199 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79623
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Robert Brown <robert.brown@HIDDEN>
Cc: 79623 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 79623-submit <at> debbugs.gnu.org id=B79623.176128727214199
          (code B ref 79623); Fri, 24 Oct 2025 06:28:02 +0000
Received: (at 79623) by debbugs.gnu.org; 24 Oct 2025 06:27:52 +0000
Received: from localhost ([127.0.0.1]:34919 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1vCBHE-0003gv-8t
	for submit <at> debbugs.gnu.org; Fri, 24 Oct 2025 02:27:52 -0400
Received: from mail-pl1-x635.google.com ([2607:f8b0:4864:20::635]:43276)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <casouri@HIDDEN>) id 1vCBHB-0003gQ-Jc
 for 79623 <at> debbugs.gnu.org; Fri, 24 Oct 2025 02:27:50 -0400
Received: by mail-pl1-x635.google.com with SMTP id
 d9443c01a7336-273a0aeed57so33690275ad.1
 for <79623 <at> debbugs.gnu.org>; Thu, 23 Oct 2025 23:27:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1761287263; x=1761892063; darn=debbugs.gnu.org;
 h=to:references:message-id:content-transfer-encoding:cc:date
 :in-reply-to:from:subject:mime-version:from:to:cc:subject:date
 :message-id:reply-to;
 bh=H3k9xGZaI4cjZsrSaq9Bk4ZzZflKB2fUdqKTCWNQu6o=;
 b=Jw3VSxXbRosxnU571liZvS6QZztzQXVuYL5kgQiTx9h2RjZorkojb9dcHJS+JFDZ+g
 wrb7fgMwfypNc8zJUnBlLKhc0uC3xIeZkuSIN0jRvmcJak3EqcpCyWdfRSTniONpt9F9
 3k/kO4i65OQ7pnL0xzWVrmIPyYGwrcZhP+nYe7LDPyrFpSjLsTptBIB0f2ZzbG5uTVAB
 pBMIczsyffrjt+DVjDPi025dxaiQkFK9xKZmwKoZQXAkyS7huBUDasvWv9k4txTHQfty
 4diiPc2+OinoQ1scw5E/Puzp9LQHCnZhKvHWAl0RXIkwIFLD5wsxAkb41HND+v+dJF8Q
 4qUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1761287263; x=1761892063;
 h=to:references:message-id:content-transfer-encoding:cc:date
 :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to;
 bh=H3k9xGZaI4cjZsrSaq9Bk4ZzZflKB2fUdqKTCWNQu6o=;
 b=JyfPNxi6amFEDcZp/AZGtxT7yiRMdKqwqGfbykpqSagp5GSiO2uaujYlZvoPpvOSQ9
 XvgnSXfsp4EUua5TCUoEL1mLqN9NUmntuQCXSHyMYIAKfG533UdljSArLi8Lm63attj+
 sQw7KHT4ZWD13PrsT+UoTob64sNqukCsDECjvK/742P6tdGmTKnG5kpagtVPhtcHR1dr
 qR5C/bdecNemGcWhmuEcnxAd03QSCvw90WffAHC3WVKrtpcxkHywb/wkzx1VZoGXzX8z
 GkJWZopbGVX8thjw05ogbGXNrbiVEHJOcyYc+V+I92jii0ew1QFgdLTk6qLOtsZVyTBi
 f4lA==
X-Forwarded-Encrypted: i=1;
 AJvYcCWMQ2mW1kkx1FT6iD2wI7MEyD5nquU7XcG4pcWSQu3xCssLLoOdjG6o/03cBbvCUisccX6ylA==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YyxprfKF5ofMFlZyg7DAXAkRtjTQs3vO1WuBmEWncFQZ0WkLcXz
 3C+hYo6t8vaI+W25K44XRAD3Qs0sYAlHeV+4/x2QvZO4AFNILUeEKK+H
X-Gm-Gg: ASbGncveaDcxtbxuFWyLxEjAPt1Pp319IdTw7fpUoPFXp3mX5ZgXeaGwnbJt2iyNWX/
 mNVQfHaFd35eAdmlArWH8Volcmf5R0gCyGwrtFyI/w4ctx/rXxiLu72nDb72iiu6icDsJJ0Xry3
 nyGdwWJd0kWjJwijXZ3Iix/8/1AALbdT7g+i3dQWG+c5vijhn0KEJKhdtgMxjAuCZ8YOmUNQoT0
 cC+mAMSlCKjT19DBVxgaNtHcT0B2eDIx6OvcB5l+iGM7blLEIEZCgNAG9LK1p7ZasGbuPAKJM63
 dKdW3DTMZjQsQy1L6mY9iblLV5ZPjpmsPL5OIYj/S9wIw4UTrLcyx4Pf/2OAZQUaL64nyDzGVeg
 mvRyhFKcp7a+VbDvx0lydW60iu/GazKz8WTqukkrofzLNSKvPkWF74p/97MhcEbgHe5I+gFFcGj
 BwEvMOtSjgbWlKmvY7ta76p2Z5XtgcqgfA+BjsTYHrBXbSvJL9
X-Google-Smtp-Source: AGHT+IESm9Az+y7e/2JVQAn6DlFqXScQi1b/DTO8VnBp5Z5iLEG3Ne0R3IskQTWW6yoUhH6O1Vd1Lg==
X-Received: by 2002:a17:903:2446:b0:25d:510:622c with SMTP id
 d9443c01a7336-29489e6921fmr20780275ad.28.1761287263106; 
 Thu, 23 Oct 2025 23:27:43 -0700 (PDT)
Received: from smtpclient.apple (c-24-4-247-194.hsd1.ca.comcast.net.
 [24.4.247.194]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2946e2283a1sm43595385ad.101.2025.10.23.23.27.42
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Thu, 23 Oct 2025 23:27:42 -0700 (PDT)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\))
From: Yuan Fu <casouri@HIDDEN>
In-Reply-To: <CAPNkkpmWEqSdesj6Q+B9xTpMYjL5frXgHmJLveREMGtXKDAwhg@HIDDEN>
Date: Thu, 23 Oct 2025 23:27:31 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <9755CB3C-8925-4D7E-A920-700FF3297568@HIDDEN>
References: <CAPNkkpnvn4D=wwbvSnLhh0qH3GZfAVb1bijnsE-UKkPwpXGgKw@HIDDEN>
 <86a51t32f6.fsf@HIDDEN>
 <CAPNkkpmWEqSdesj6Q+B9xTpMYjL5frXgHmJLveREMGtXKDAwhg@HIDDEN>
X-Mailer: Apple Mail (2.3826.700.81)
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)



> On Oct 14, 2025, at 9:50=E2=80=AFAM, Robert Brown =
<robert.brown@HIDDEN> wrote:
>=20
> 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
>=20
>     int foo =3D bar;
>     baz =3D 100;
>=20
> 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=E2=80=99s 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=E2=80=99ll 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=

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#79623: 30.1; c-ts-mode wrong face for variable assignments
Resent-From: Robert Brown <robert.brown@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 07 Nov 2025 15:01:02 +0000
Resent-Message-ID: <handler.79623.B79623.176252766112275 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79623
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Yuan Fu <casouri@HIDDEN>
Cc: 79623 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 79623-submit <at> debbugs.gnu.org id=B79623.176252766112275
          (code B ref 79623); Fri, 07 Nov 2025 15:01:02 +0000
Received: (at 79623) by debbugs.gnu.org; 7 Nov 2025 15:01:01 +0000
Received: from localhost ([127.0.0.1]:46117 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1vHNxV-0003Bk-63
	for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:01:01 -0500
Received: from mail-pl1-x62f.google.com ([2607:f8b0:4864:20::62f]:56383)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <robert.brown@HIDDEN>)
 id 1vHNxS-0003Ba-9b
 for 79623 <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:00:58 -0500
Received: by mail-pl1-x62f.google.com with SMTP id
 d9443c01a7336-294fe7c2e69so9314405ad.0
 for <79623 <at> debbugs.gnu.org>; Fri, 07 Nov 2025 07:00:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1762527652; x=1763132452; darn=debbugs.gnu.org;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=+iNac4zRIj+B2QHp7y1OSiECLdR3jwYKKbWL6qS0nXA=;
 b=Ry2GDL5BRfHrTCyX6q3HMl9e+raXboGY+v053GsunqLBmH3tYQEuFVaX79KPo34cEU
 ogZNhNRV4V3u+NDyieZVFXWXcn22ggidL8Fl4dhLOBboHtXL3GD1Jk0eG1gUYbljGwOb
 Ku4cZaESzu6+6sNytenMBBy9o30KpEF5E9QSXSkBGrf1jXlVnflNrOMHOKQBwHgdXGdz
 5ORNuFXaEouG8PFJyK6R5BC62XkNBCw/XRl3V3iwt85ZfE88jCLNgHW0FXtSuqIVt5Nc
 fJbfCwxYmnnBQlOBBO+QN4kG0urvV7PwU7NOFxSuMjOuPVLRqDvQUHwh59HnX+ZMIJ/B
 ijBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1762527652; x=1763132452;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
 :message-id:reply-to;
 bh=+iNac4zRIj+B2QHp7y1OSiECLdR3jwYKKbWL6qS0nXA=;
 b=VTQc2OJCayb0QLX8TQHKRZXWf+rQ+39UdGRj5ROISJlr2eRGEzUzCXLsrai3z8MPC3
 Wf0byhqbyBODEwRSL+e9GnQ/xd73o03NwP0GAH0dZe8aWTh0RZTjWHfS0Ctt7m1lIa/8
 BV03+MEfc7DwsiVd0iNQGI0m5m4kdrwC8hRgZwxmnkexvLgija+wpybeOLBdC4s9dyt5
 Be5l1TL4j9Ex++AWEW4awz0U5HCRYCK3VmBkht3NsZUm9pBzeAXeM/Sg2DpKZDV8RLXO
 wVVw4f5V2POUHOgP0uFlNMw+/rG2Ley/AdRPuaaID2lEwU9HJOEG3CyAYsDcs3PS3lHb
 Qs/g==
X-Forwarded-Encrypted: i=1;
 AJvYcCXRPj48YGwGBWyV8Y4GQrJZofDIhsl3PsaKMB6Hi4146JfNRq8sxX0UWGwzBpmyZlc+VFmzeg==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YxUHp0iZL0lktA06PHNWsg0p05/A1vFNbImuomrBxzf9Q+/esQS
 PdTYFd3jjxeq2EOj92R7KHNgxkgUE5KAqrXrRQ+8gINKbzdvVFoMcuhsEf2/v3x/T9EtqaS0qeR
 u+JZGbzHmpccJUJ/6j+SgXPYN3OAQQvVFObWa
X-Gm-Gg: ASbGnctebmGVPFmW7D2guJ7gjswbBXbwPIMyP3zAQTl2MYCh4oMWgrX4Pax/D8dY180
 DfHVYLd5Rygo6GoOJ+0tslZbPQ8wCCHxu9pZ1/jbWOwVvEa1oJKoDSC2FH9s8UOTBV68jUlQyxh
 ecuShy51EuUuwmjYn0QewF4OEDuWkgN6ZkvW+tV4/hQRmC3Eo1o5+3L1qDA3pXgdFS1EhWh025q
 dK2wSDbfGbTaJxO/MiW4ui3C/nfqcY3DjC2jVvau27GMBN2pMgV9vuZgi0G
X-Google-Smtp-Source: AGHT+IEiHqfpC0eQmLXSIoccgHiVgdNsziBf62IWtuFqWzaAHOL8Ih476rtyHw5zDoZyLIF98wpYSFl6F5fJVHl7P7k=
X-Received: by 2002:a17:902:e78e:b0:294:fcae:826 with SMTP id
 d9443c01a7336-297c0478227mr47311565ad.59.1762527651000; Fri, 07 Nov 2025
 07:00:51 -0800 (PST)
MIME-Version: 1.0
References: <CAPNkkpnvn4D=wwbvSnLhh0qH3GZfAVb1bijnsE-UKkPwpXGgKw@HIDDEN>
 <86a51t32f6.fsf@HIDDEN>
 <CAPNkkpmWEqSdesj6Q+B9xTpMYjL5frXgHmJLveREMGtXKDAwhg@HIDDEN>
 <9755CB3C-8925-4D7E-A920-700FF3297568@HIDDEN>
In-Reply-To: <9755CB3C-8925-4D7E-A920-700FF3297568@HIDDEN>
From: Robert Brown <robert.brown@HIDDEN>
Date: Fri, 7 Nov 2025 10:00:39 -0500
X-Gm-Features: AWmQ_bkP-xqR0y_1kE7ElgLYB1qrK3shv013D-7_TfhMMmTnHhhytXrZ6k4gQXc
Message-ID: <CAPNkkpnUQ3AoYNpxQrB5WfQzmGBVhq66WS9S1v9OeGAVpAcTTA@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000008b781b06430272e8"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--0000000000008b781b06430272e8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I do not believe any tree sitter modes make a fontification distinction
between a variable used on the LHS vs. RHS of an assignment, except for
variable declarations.  Historically, variables at the point of declaration
have been fontified using variable-name-face. The face
variable-name-face was the only face used for variables before the
introduction of tree sitter modes and it was only used at the point where a
variable is declared.

With the following code

int foo =3D 100;  // line 1
foo =3D 200;      // line 2
foo =3D bar;      // line 3

c-mode fontifies foo on line 1 using variable-name-face.  There's
no special fontification for variables foo and bar on lines 2 and 3.

In addition to variable-name-face tree sitter modes now additionally use a
recently added face called variable-use-face.  I believe variable-use-face
is employed everywhere a variable is used after the point of declaration.
For assignments, it's used on both the LHS and RHS of assignments.

Unfortunately, c-ts-mode doesn't currently use variable-use-face.  Instead,
it fontifies every instance of foo above using variable-name-face and bar
using the default face.  I think the approach that's consistent with other
tree sitter modes is to use variable-name-face for foo on line 1, where the
variable is defined, and to use variable-use-face for foo and bar on lines
2 and 3.

On Fri, Oct 24, 2025 at 2:27=E2=80=AFAM Yuan Fu <casouri@HIDDEN> wrote:

>
>
> > On Oct 14, 2025, at 9:50=E2=80=AFAM, Robert Brown <robert.brown@HIDDEN=
om>
> 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 =3D bar;
> >     baz =3D 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 usin=
g
> font-lock-variable-name-face.  Instead, it should use
> font-lock-variable-use-face, ideally for both bar and baz.  That allows m=
e
> to duplicate the behavior of c-mode in c-ts-mode by overriding the defaul=
t
> 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=E2=80=99s fontification. But still, using different faces f=
or LHS and
> RHS of an assignment makes more sense to me, since they have distinct
> connotations. So I=E2=80=99ll make it configurable to either use variable=
-name-face
> or variable-use-face for the LHS. Or should I instead allow user to choos=
e
> whether to fontify the LHS variable? Hmm...
>
> Yuan

--0000000000008b781b06430272e8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I do not believe any tree sitter modes make a fontificatio=
n distinction between a variable used on the LHS=C2=A0vs. RHS of an assignm=
ent, except for	variable declarations.=C2=A0 Historically, variables at=C2=
=A0the point of declaration have been fontified using variable-name-face.	T=
he face variable-name-face=C2=A0was the only face used for variables before=
 the	introduction of	tree sitter modes and it=C2=A0was only used at the poi=
nt where a variable	is declared.<div><br></div><div>With the following code=
<br><br>int foo =3D 100; =C2=A0// line 1<br>foo =3D 200; =C2=A0 =C2=A0 =C2=
=A0// line 2<br>foo =3D bar; =C2=A0 =C2=A0 =C2=A0// line 3<br><br>c-mode fo=
ntifies foo on line 1 using variable-name-face.=C2=A0 There&#39;s no=C2=A0s=
pecial fontification for variables foo and bar on lines 2 and 3.</div><div>=
<br></div><div>In addition to variable-name-face tree sitter modes now addi=
tionally use a recently added face called variable-use-face.=C2=A0 I believ=
e variable-use-face is employed everywhere a variable is used after the poi=
nt of declaration.=C2=A0 For assignments, it&#39;s used on both the LHS and=
 RHS of assignments.<br><br>Unfortunately, c-ts-mode doesn&#39;t currently =
use variable-use-face.=C2=A0 Instead, it fontifies every instance of foo ab=
ove using variable-name-face and bar using the default face.=C2=A0 I think =
the approach that&#39;s consistent with other tree sitter modes is to use v=
ariable-name-face for foo on line 1, where the variable is defined, and to =
use variable-use-face for foo and bar on lines 2 and 3.<br></div><div><br><=
/div></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D=
"ltr" class=3D"gmail_attr">On Fri, Oct 24, 2025 at 2:27=E2=80=AFAM Yuan Fu =
&lt;<a href=3D"mailto:casouri@HIDDEN">casouri@HIDDEN</a>&gt; wrote:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
&gt; On Oct 14, 2025, at 9:50=E2=80=AFAM, Robert Brown &lt;<a href=3D"mailt=
o:robert.brown@HIDDEN" target=3D"_blank">robert.brown@HIDDEN</a>&gt; =
wrote:<br>
&gt; <br>
&gt; c-mode only uses font-lock-variable-name-face.=C2=A0 Uses of variables=
 are fontified with the default face.=C2=A0 That&#39;s actually the behavio=
r I prefer.=C2=A0 So with the statements<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0int foo =3D bar;<br>
&gt;=C2=A0 =C2=A0 =C2=A0baz =3D 100;<br>
&gt; <br>
&gt; c-mode fontifies foo using font-lock-variable-name-face but bar and ba=
z are rendered using the default face.=C2=A0 Traditionally, font-lock-varia=
ble-name-face has only been used to highlight variables where they are defi=
ned.<br>
<br>
&gt; c-ts-mode differs from c-mode in that it fontifies baz but not bar usi=
ng font-lock-variable-name-face.=C2=A0 Instead, it should use font-lock-var=
iable-use-face, ideally for both bar and baz.=C2=A0 That allows me to dupli=
cate the behavior of c-mode in c-ts-mode by overriding the default definiti=
on of font-lock-variable-use-face, setting it to be the default face.=C2=A0=
 Alternatively, cs-ts-mode could stop fontifying baz using font-lock-variab=
le-name-face.<br>
<br>
When the difference is subjective, I have no problem making c-ts-mode follo=
w c-mode=E2=80=99s fontification. But still, using different faces for LHS =
and RHS of an assignment makes more sense to me, since they have distinct c=
onnotations. So I=E2=80=99ll make it configurable to either use variable-na=
me-face or variable-use-face for the LHS. Or should I instead allow user to=
 choose whether to fontify the LHS variable? Hmm...<br>
<br>
Yuan</blockquote></div>

--0000000000008b781b06430272e8--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#79623: 30.1; c-ts-mode wrong face for variable assignments
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 25 Nov 2025 20:19:03 +0000
Resent-Message-ID: <handler.79623.B79623.17641019402079 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79623
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: casouri@HIDDEN, Robert Brown <robert.brown@HIDDEN>
Cc: 79623 <at> debbugs.gnu.org
Received: via spool by 79623-submit <at> debbugs.gnu.org id=B79623.17641019402079
          (code B ref 79623); Tue, 25 Nov 2025 20:19:03 +0000
Received: (at 79623) by debbugs.gnu.org; 25 Nov 2025 20:19:00 +0000
Received: from localhost ([127.0.0.1]:41664 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1vNzV5-0000XQ-NS
	for submit <at> debbugs.gnu.org; Tue, 25 Nov 2025 15:19:00 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:48252)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vMk8Y-0008LL-41
 for 79623 <at> debbugs.gnu.org; Sat, 22 Nov 2025 04:42:34 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1vMk8D-0003BV-ME; Sat, 22 Nov 2025 04:42:13 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
 Date; bh=EQQN18fWajMU2PQ+oVBd1ji96HysxbYdsKrJv1NDeXg=; b=Udz/aK6ndalyjVPjrzZK
 Ufxmd1V+k+d1rq5HzRsp4p2hG27aSCmZVVpVgAk+quRE5ApHqQmk0aTsurilhKtNewp+lkjrYck42
 HPFjPYtFAc2VYPmsDw7bSRu2Uk7C2pYLTY/jPoTqlc8wL3g+4iyB9ab2IvXWJvXrair6A0++whniS
 EpW4ehZTfscBLdiOft+EJe9R2QessiYUQGu4/vvn2o7ClmYC3JiO3acEP0u6/+xyVZwot1GaCE9AL
 8LWi5oh18QHOLuHjw35HQ1ai41DcS389cnDVClvISU7w7kSylMj5Z7tacqtuOgyeNPu63yRpjjPop
 FDkrkj5w9CmIQg==;
Date: Sat, 22 Nov 2025 11:42:03 +0200
Message-Id: <864iqmh09g.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <CAPNkkpnUQ3AoYNpxQrB5WfQzmGBVhq66WS9S1v9OeGAVpAcTTA@HIDDEN>
 (message from Robert Brown on Fri, 7 Nov 2025 10:00:39 -0500)
References: <CAPNkkpnvn4D=wwbvSnLhh0qH3GZfAVb1bijnsE-UKkPwpXGgKw@HIDDEN>
 <86a51t32f6.fsf@HIDDEN>
 <CAPNkkpmWEqSdesj6Q+B9xTpMYjL5frXgHmJLveREMGtXKDAwhg@HIDDEN>
 <9755CB3C-8925-4D7E-A920-700FF3297568@HIDDEN>
 <CAPNkkpnUQ3AoYNpxQrB5WfQzmGBVhq66WS9S1v9OeGAVpAcTTA@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Ping! Yuan, how should we make further progress with this issue?

> From: Robert Brown <robert.brown@HIDDEN>
> Date: Fri, 7 Nov 2025 10:00:39 -0500
> Cc: Eli Zaretskii <eliz@HIDDEN>, 79623 <at> debbugs.gnu.org
> 
> I do not believe any tree sitter modes make a fontification distinction between a variable used on the LHS
> vs. RHS of an assignment, except for variable declarations.  Historically, variables at the point of declaration
> have been fontified using variable-name-face. The face variable-name-face was the only face used for
> variables before the introduction of tree sitter modes and it was only used at the point where a variable is
> declared.
> 
> With the following code
> 
> int foo = 100;  // line 1
> foo = 200;      // line 2
> foo = bar;      // line 3
> 
> c-mode fontifies foo on line 1 using variable-name-face.  There's no special fontification for variables foo
> and bar on lines 2 and 3.
> 
> In addition to variable-name-face tree sitter modes now additionally use a recently added face called
> variable-use-face.  I believe variable-use-face is employed everywhere a variable is used after the point of
> declaration.  For assignments, it's used on both the LHS and RHS of assignments.
> 
> Unfortunately, c-ts-mode doesn't currently use variable-use-face.  Instead, it fontifies every instance of foo
> above using variable-name-face and bar using the default face.  I think the approach that's consistent with
> other tree sitter modes is to use variable-name-face for foo on line 1, where the variable is defined, and to
> use variable-use-face for foo and bar on lines 2 and 3.
> 
> On Fri, Oct 24, 2025 at 2:27 AM Yuan Fu <casouri@HIDDEN> wrote:
> 
>  > On Oct 14, 2025, at 9:50 AM, Robert Brown <robert.brown@HIDDEN> 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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#79623: 30.1; c-ts-mode wrong face for variable assignments
Resent-From: Yuan Fu <casouri@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 25 Nov 2025 20:23:09 +0000
Resent-Message-ID: <handler.79623.B79623.17641021844830 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79623
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 79623 <at> debbugs.gnu.org, Robert Brown <robert.brown@HIDDEN>
Received: via spool by 79623-submit <at> debbugs.gnu.org id=B79623.17641021844830
          (code B ref 79623); Tue, 25 Nov 2025 20:23:09 +0000
Received: (at 79623) by debbugs.gnu.org; 25 Nov 2025 20:23:04 +0000
Received: from localhost ([127.0.0.1]:41953 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1vNzZ1-0001FV-8w
	for submit <at> debbugs.gnu.org; Tue, 25 Nov 2025 15:23:04 -0500
Received: from mail-pg1-x52b.google.com ([2607:f8b0:4864:20::52b]:53368)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <casouri@HIDDEN>) id 1vNGmn-0003EG-NW
 for 79623 <at> debbugs.gnu.org; Sun, 23 Nov 2025 15:34:19 -0500
Received: by mail-pg1-x52b.google.com with SMTP id
 41be03b00d2f7-b6ceb3b68eeso3535179a12.2
 for <79623 <at> debbugs.gnu.org>; Sun, 23 Nov 2025 12:34:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1763930051; x=1764534851; darn=debbugs.gnu.org;
 h=to:references:message-id:content-transfer-encoding:cc:date
 :in-reply-to:from:subject:mime-version:from:to:cc:subject:date
 :message-id:reply-to;
 bh=vj/GF2ynS3w0etcoG3GlrNj6liA9aawoNg8aCnwnZ6o=;
 b=MvxuEeO1qOImxXAl5vUzBEygeYP37SK1fmNPIrecxf48mWFaLp2fSNlGLqYs9KBvjV
 sow74faFjMhIh9TZtpqOmh75LhX0MmRQZFtTmkPJLJ7kshsHBmpfPLiAPGyYDxsjWCS/
 U3iv4Z+L5+5We/qqcEVindApSXdPe6Nhs8gcpm2b6P8gjFZ1UoYfejz42aj8MaWrsq/8
 lT8HsjHTkpTKhlyeUVoFuaFNLn+RmExejI5nHINyJkxsRkoH32vD9I/9f8g+b8Kycf8k
 tuHr9OQPNwVcRneKHTsJB6tIMzoPf5LVbKzcUEBtGeaGkLh0JXtWgjwx8UE/Pj3ZgEp1
 rjFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1763930051; x=1764534851;
 h=to:references:message-id:content-transfer-encoding:cc:date
 :in-reply-to:from:subject:mime-version:x-gm-gg:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=vj/GF2ynS3w0etcoG3GlrNj6liA9aawoNg8aCnwnZ6o=;
 b=owCRKKZhWmBlONN2kLO913O9PVD+xSdxJFDTde8R0dnFqH20E091txG8IZ2D5c/IZt
 JI64sWGRHLsdvrYVeTF607Dj/ld9z9oxwSvQozVGCAs8fs35KAk7OqHaKpuzS2ki9jFL
 A3tnuXyfXpd7YzN7tHgcVAFgcGpPbt8UIKqBgMHEe5d5GbUC8D8g1KZj9HQfrjeSjqgB
 FhFMPGStN4Pi+z3+LCxLEOkVVujdF90DyuzdJPNhpjrjox574rzci1DmoQtVCQaokiKZ
 uTo1TfKEj0C6TbxUCbKe0eeShrknN0UDJfZlAxvcwLcLoWSTAilMKSZomFyWaV94Ubcw
 CKNA==
X-Forwarded-Encrypted: i=1;
 AJvYcCWYSuW1LgrBscj/h3/19PcPOu5NzAWAmZ53Z7e1iIKZ8goZrIoBSY0Fs9+wQe0v7dFQuub+kQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YykHuNkUPHTUpdwkTjZiettgMUCwa7qRfmAgWEG4rcTxrlShyD8
 sk1Dmj/FGb3Yw/1Qq727tH89NO4aV1TrnQtnqAjXilEovpIMvikrqpCP
X-Gm-Gg: ASbGnctyjBUtRylDDI+LVVaIjBw17XAlKW7keQ+sXtypfm/vroiCEqdwqgalK4Mg2L7
 YpnaqrndW3zMqKxAADpD9tdwKHPmrXDhyIYoiz6Wm9aBkClx0y5Bi6QfGEH1LWcSUsLGF/wfCFb
 rlw9wutnwFhkNwGUqMp8Qjx/zQl9P3dhL9LaV94HHOqn+r7O1Ss5IvWrhMft3wRuxn65XgYO8OD
 vcg+xQnttBtwyGKDUajZ+xKoQ+VBU3HPukP6iXKjB1NzufQQQXU6/2gF2wjqvUbdA1o1LX1p44Z
 JR4kxg8Mj7vPUDrmbECfIkMGsv4xt+RDvh7znvl3N6g/wbHpqPSIcD8PTlh6IOs+bYROvQj5HIt
 4p8phKCPDAtZklkX2P4wmbOZ+WoL4i8tPddbF6Zefd2Xpo7/ZpW55c8jSHcD/uwgsZ9RwErpIaq
 lnhk80guOopuMVNp7YriW9ghrMlMzeYQX544i0ol51wkOYffZpxbP4npDqxtVR0GfDRvhs+w==
X-Google-Smtp-Source: AGHT+IG9QRxawBZpSMZ/LJBvSGNUNzAYG6guxMGkt75bdOib2CH04K/gdKe9Hs+PULFXP2w4Y9HLhQ==
X-Received: by 2002:a05:7301:4616:b0:2a4:50ca:9234 with SMTP id
 5a478bee46e88-2a719d7d25cmr3896795eec.26.1763930051382; 
 Sun, 23 Nov 2025 12:34:11 -0800 (PST)
Received: from smtpclient.apple (c-24-4-247-194.hsd1.ca.comcast.net.
 [24.4.247.194]) by smtp.gmail.com with ESMTPSA id
 5a478bee46e88-2a6fc4f6671sm57922175eec.3.2025.11.23.12.34.10
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Sun, 23 Nov 2025 12:34:10 -0800 (PST)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\))
From: Yuan Fu <casouri@HIDDEN>
In-Reply-To: <864iqmh09g.fsf@HIDDEN>
Date: Sun, 23 Nov 2025 12:33:59 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <89C13D92-0014-458A-9FE1-BB34BF4C46EA@HIDDEN>
References: <CAPNkkpnvn4D=wwbvSnLhh0qH3GZfAVb1bijnsE-UKkPwpXGgKw@HIDDEN>
 <86a51t32f6.fsf@HIDDEN>
 <CAPNkkpmWEqSdesj6Q+B9xTpMYjL5frXgHmJLveREMGtXKDAwhg@HIDDEN>
 <9755CB3C-8925-4D7E-A920-700FF3297568@HIDDEN>
 <CAPNkkpnUQ3AoYNpxQrB5WfQzmGBVhq66WS9S1v9OeGAVpAcTTA@HIDDEN>
 <864iqmh09g.fsf@HIDDEN>
X-Mailer: Apple Mail (2.3826.700.81)
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)



> On Nov 22, 2025, at 1:42=E2=80=AFAM, Eli Zaretskii <eliz@HIDDEN> =
wrote:
>=20
> Ping! Yuan, how should we make further progress with this issue?
>=20

I=E2=80=99ll change it to fontifying the LHS for variable declaration as =
Robert suggested. I realized that the assignment feature is more =
suitable for fontifying the LHS for assignments. But I=E2=80=99ll get to =
it and bug#79823 before this year ends :-)

Yuan

>> From: Robert Brown <robert.brown@HIDDEN>
>> Date: Fri, 7 Nov 2025 10:00:39 -0500
>> Cc: Eli Zaretskii <eliz@HIDDEN>, 79623 <at> debbugs.gnu.org
>>=20
>> I do not believe any tree sitter modes make a fontification =
distinction between a variable used on the LHS
>> vs. RHS of an assignment, except for variable declarations.  =
Historically, variables at the point of declaration
>> have been fontified using variable-name-face. The face =
variable-name-face was the only face used for
>> variables before the introduction of tree sitter modes and it was =
only used at the point where a variable is
>> declared.
>>=20
>> With the following code
>>=20
>> int foo =3D 100;  // line 1
>> foo =3D 200;      // line 2
>> foo =3D bar;      // line 3
>>=20
>> c-mode fontifies foo on line 1 using variable-name-face.  There's no =
special fontification for variables foo
>> and bar on lines 2 and 3.
>>=20
>> In addition to variable-name-face tree sitter modes now additionally =
use a recently added face called
>> variable-use-face.  I believe variable-use-face is employed =
everywhere a variable is used after the point of
>> declaration.  For assignments, it's used on both the LHS and RHS of =
assignments.
>>=20
>> Unfortunately, c-ts-mode doesn't currently use variable-use-face.  =
Instead, it fontifies every instance of foo
>> above using variable-name-face and bar using the default face.  I =
think the approach that's consistent with
>> other tree sitter modes is to use variable-name-face for foo on line =
1, where the variable is defined, and to
>> use variable-use-face for foo and bar on lines 2 and 3.
>>=20
>> On Fri, Oct 24, 2025 at 2:27=E2=80=AFAM Yuan Fu <casouri@HIDDEN> =
wrote:
>>=20
>>> On Oct 14, 2025, at 9:50=E2=80=AFAM, Robert Brown =
<robert.brown@HIDDEN> wrote:
>>>=20
>>> 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
>>>=20
>>>    int foo =3D bar;
>>>    baz =3D 100;
>>>=20
>>> 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.
>>=20
>>> 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.
>>=20
>> When the difference is subjective, I have no problem making c-ts-mode =
follow c-mode=E2=80=99s 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=E2=80=99ll 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...
>>=20
>> Yuan

Last modified: Tue, 25 Nov 2025 20:30:02 UTC

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