Received: (at 79623) by debbugs.gnu.org; 25 Nov 2025 20:23:04 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 25 15:23:04 2025 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\)) Subject: Re: bug#79623: 30.1; c-ts-mode wrong face for variable assignments 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> To: Eli Zaretskii <eliz@HIDDEN> X-Mailer: Apple Mail (2.3826.700.81) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79623 Cc: 79623 <at> debbugs.gnu.org, Robert Brown <robert.brown@HIDDEN> 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
bug-gnu-emacs@HIDDEN:bug#79623; Package emacs.
Full text available.Received: (at 79623) by debbugs.gnu.org; 25 Nov 2025 20:19:00 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 25 15:19:00 2025 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> To: casouri@HIDDEN, Robert Brown <robert.brown@HIDDEN> In-Reply-To: <CAPNkkpnUQ3AoYNpxQrB5WfQzmGBVhq66WS9S1v9OeGAVpAcTTA@HIDDEN> (message from Robert Brown on Fri, 7 Nov 2025 10:00:39 -0500) Subject: Re: bug#79623: 30.1; c-ts-mode wrong face for variable assignments 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-Debbugs-Envelope-To: 79623 Cc: 79623 <at> debbugs.gnu.org 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
bug-gnu-emacs@HIDDEN:bug#79623; Package emacs.
Full text available.Received: (at 79623) by debbugs.gnu.org; 7 Nov 2025 15:01:01 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 10:01:01 2025 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> Subject: Re: bug#79623: 30.1; c-ts-mode wrong face for variable assignments To: Yuan Fu <casouri@HIDDEN> Content-Type: multipart/alternative; boundary="0000000000008b781b06430272e8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79623 Cc: 79623 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> 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'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's used on both the LHS and= RHS of assignments.<br><br>Unfortunately, c-ts-mode doesn'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'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 = <<a href=3D"mailto:casouri@HIDDEN">casouri@HIDDEN</a>> 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> > On Oct 14, 2025, at 9:50=E2=80=AFAM, Robert Brown <<a href=3D"mailt= o:robert.brown@HIDDEN" target=3D"_blank">robert.brown@HIDDEN</a>> = wrote:<br> > <br> > c-mode only uses font-lock-variable-name-face.=C2=A0 Uses of variables= are fontified with the default face.=C2=A0 That's actually the behavio= r I prefer.=C2=A0 So with the statements<br> > <br> >=C2=A0 =C2=A0 =C2=A0int foo =3D bar;<br> >=C2=A0 =C2=A0 =C2=A0baz =3D 100;<br> > <br> > 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> > 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--
bug-gnu-emacs@HIDDEN:bug#79623; Package emacs.
Full text available.Received: (at 79623) by debbugs.gnu.org; 24 Oct 2025 06:27:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 24 02:27:52 2025 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\)) Subject: Re: bug#79623: 30.1; c-ts-mode wrong face for variable assignments 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> To: Robert Brown <robert.brown@HIDDEN> X-Mailer: Apple Mail (2.3826.700.81) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79623 Cc: 79623 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> 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=
bug-gnu-emacs@HIDDEN:bug#79623; Package emacs.
Full text available.
Received: (at 79623) by debbugs.gnu.org; 14 Oct 2025 16:50:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 14 12:50:57 2025
Received: from localhost ([127.0.0.1]:41305 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v8iEi-0007Dv-H4
for submit <at> debbugs.gnu.org; Tue, 14 Oct 2025 12:50:57 -0400
Received: from mail-pl1-x62f.google.com ([2607:f8b0:4864:20::62f]:59728)
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 1v8iEf-0007Dg-0r
for 79623 <at> debbugs.gnu.org; Tue, 14 Oct 2025 12:50:53 -0400
Received: by mail-pl1-x62f.google.com with SMTP id
d9443c01a7336-27c369f898fso79684885ad.3
for <79623 <at> debbugs.gnu.org>; Tue, 14 Oct 2025 09:50:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1760460646; x=1761065446; 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=pel8a85DF8oSU4EAIJGEp13JxCln7+1X9NfPXq/3/Dk=;
b=h3kneRgYgbIj5H7mo5IVBTm3y6T697GoMo8YhRG2zOSEW1WqmD9VA0/KVPyMSxE0oC
SbooswyQotnoR0gGO0DLRRGI11iBuhFv2z51rTvltNg/sf/sxXZc1NYgZRq0odj4r+ls
BIbOBlpEqGz4Rg1sOuJ2LI5GdCZE4R4z0t1+QwSKFZMWRb0cfPlD6srfoTxvBPp5+mS8
j6a6mvd/8tx5jlLYpqXAhSTzGSz/rUFnAxT3DsnCs/ZGKNtRDGxfoeMbsoMtMp2roY+t
Jd3XL6fzdNof1ex2mJwBNc13nUla63nYHBP0W8i7LOB6PP7jVSmfGym0anOZBjt73CgC
RWEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1760460646; x=1761065446;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=pel8a85DF8oSU4EAIJGEp13JxCln7+1X9NfPXq/3/Dk=;
b=K4Y6Hk5tWrHjB4/4TkMJFZ88781S/DKtIipxxEn29c8K7dW7lA5U/7+XuaNmZKPa++
DjI/H22m8nuplj4AaFgdV0fIRPAuWMHrN3d584t1ne8+8jMCPz+71ASjatP0Ms9Fknyq
kHUVbV2qFq+EF7zsNTbGiaoQuf7r+zNOprKyMg2UO/9T0orczvM18Hqh/Gt//q8r624c
KYccjW5qZ3I3cF4rrTZQCDGmlP3p8+ZUvD46hUIKe5lxWG8E33rQ2s/rYgL2ArqbTnTA
TZCbX3bLGN17NKYo6A4MnzMjIRRFlCW2AXzpKfP/VPQ5fXl3d2ZVnp8oRFVOqgxdz2Uv
9lxw==
X-Forwarded-Encrypted: i=1;
AJvYcCWsLpAS8PhPIsBujU38gpZKMNcwO9KppKFqnVG0HiS1ULZv8LayyVf7wcXIseyZ9g46tbzBgQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YwBsEssdpWblNgO43O2k/COcC23eMqE7FsgeAUSazlYfdYlZaJW
IWFVQJWI9ytouzJOokg2jht17SxQWYms+cSKwtR7i4XqqnLGbsZ/T0Oigl9H/JwVTQxxrTQJMG5
Wrdr6k9+58fqd+Y9b9UjXp9EZ07lpzBs=
X-Gm-Gg: ASbGnct1Vr7lPUKVwq2UAGd9tH2/EOWLEceTz4l1bBkW/A2KBM6G8NojjmIJr/g6dBI
ekq2u+5YGWI11IjgxOMU231AOfiJjExdbc5NT1zxwoxVce2fcHP0jwGiHzHu8Y6WEZvgcNz76XL
ZSt6FB38sbZ2nfhpG8zKoRtUmpxVD5WmD6eBCSY/yWKLVXwV1CoWK5FXR1HCViBG5FVs0RFTsvV
7Q6YapizaGpvgFVxd/hZVeUDAX3s7ZhVlu6
X-Google-Smtp-Source: AGHT+IEIwA3rxNkQTLdcHq/Kz05vpPq14l599VAVZ3/OYAw9YEYviMqKQa/eoNOuA/Z9nrX1BbSi2rgSTE3e3pM+I8Q=
X-Received: by 2002:a17:903:3c2c:b0:267:a55a:8684 with SMTP id
d9443c01a7336-290272159dcmr335499545ad.2.1760460646256; Tue, 14 Oct 2025
09:50:46 -0700 (PDT)
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
X-Gm-Features: AS18NWCURhBfnzyIuGPwo5UkK8hKtpHuXXDKrcPhz_xCpIb-HgQLOXMmipb_95s
Message-ID: <CAPNkkpmWEqSdesj6Q+B9xTpMYjL5frXgHmJLveREMGtXKDAwhg@HIDDEN>
Subject: Re: bug#79623: 30.1; c-ts-mode wrong face for variable assignments
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000007616a10641212f00"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 79623
Cc: 79623 <at> debbugs.gnu.org, Yuan Fu <casouri@HIDDEN>
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 (-)
--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'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 <<a href=3D"mailto:eliz@HIDDEN">eliz@HIDDEN</a>> 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">> From: Robert Br=
own <<a href=3D"mailto:robert.brown@HIDDEN" target=3D"_blank">robert.=
brown@HIDDEN</a>><br>
> Date: Tue, 14 Oct 2025 10:41:29 -0400<br>
> <br>
> When editing a C source file using c-ts-mode, variable assignments 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>
> problem.<br>
<br>
Thanks, but I'm not sure this is correct.=C2=A0 For starters, c-mode<br=
>
doesn'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>
> diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-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 =C2=A0;; expressions, see `c-ts-mode--fontify-declarator&=
#39; for<br>
>=C2=A0 =C2=A0 =C2=A0;; inspiration.<br>
>=C2=A0 =C2=A0 =C2=A0'((assignment_expression<br>
> -=C2=A0 =C2=A0 =C2=A0 left: (identifier) @font-lock-variable-name-face=
)<br>
> +=C2=A0 =C2=A0 =C2=A0 left: (identifier) @font-lock-variable-use-face)=
<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(assignment_expression<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 left: (field_expression field: (_) @font-lo=
ck-property-use-face))<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(assignment_expression<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 left: (pointer_expression<br>
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(identifier) @font-lo=
ck-variable-name-face))<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(identifier) @font-lo=
ck-variable-use-face))<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(assignment_expression<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 left: (subscript_expression<br>
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(identifier) @font-lo=
ck-variable-name-face))<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(identifier) @font-lo=
ck-variable-use-face))<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(init_declarator declarator: (_) @c-ts-mode-=
-fontify-declarator))<br>
>=C2=A0 <br>
>=C2=A0 =C2=A0 =C2=A0:feature 'function<br>
<br>
Yuan, WDYT?<br>
</blockquote></div>
--0000000000007616a10641212f00--
bug-gnu-emacs@HIDDEN:bug#79623; Package emacs.
Full text available.Received: (at 79623) by debbugs.gnu.org; 14 Oct 2025 15:53:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 14 11:53:44 2025 Received: from localhost ([127.0.0.1]:40493 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v8hLL-0008Vs-Vk for submit <at> debbugs.gnu.org; Tue, 14 Oct 2025 11:53:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34858) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1v8hLJ-0008VJ-7e for 79623 <at> debbugs.gnu.org; Tue, 14 Oct 2025 11:53:41 -0400 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 1v8hLD-0003RY-P2; Tue, 14 Oct 2025 11:53:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=q2vBFVKp8LruBAJ/iKXCUmrI719GO17JJYotHKIPqyY=; b=lownHEeHOoO4 KIADoNf75rnZXeedvJYun7LV/pvkv/R/oOgrxLOsrTkoCCQQqyuG5eCD/WwCCqM9ynPFhH1228EBS wMFpD7cJtA7mrTW7tk3KdvF6tQz46NFKh+YPmpdrhWKJzDDO7bTcNeM6mAAGl7TYAlwo/aIZmhssm SAWGspPE7Nx++MVpRzdI/DONmsWFZErF4q4F5/DpaK29SEpLjyo4VQh9gI2tk4IxQuH+M9bmx3iZe fJUMyfKaiUTU/6T67Sj3Isq0TdLTnTpl5CIsdv36nQNjm3FxCheDF2W2nqsgQ/V5oMJf6PXHg340v mLvV8pPmJaLJufUxd+LNaA==; Date: Tue, 14 Oct 2025 18:53:33 +0300 Message-Id: <86a51t32f6.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Robert Brown <robert.brown@HIDDEN>, Yuan Fu <casouri@HIDDEN> In-Reply-To: <CAPNkkpnvn4D=wwbvSnLhh0qH3GZfAVb1bijnsE-UKkPwpXGgKw@HIDDEN> (message from Robert Brown on Tue, 14 Oct 2025 10:41:29 -0400) Subject: Re: bug#79623: 30.1; c-ts-mode wrong face for variable assignments References: <CAPNkkpnvn4D=wwbvSnLhh0qH3GZfAVb1bijnsE-UKkPwpXGgKw@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79623 Cc: 79623 <at> debbugs.gnu.org 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 (---) > 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?
bug-gnu-emacs@HIDDEN:bug#79623; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 14 Oct 2025 14:42:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 14 10:42:08 2025
Received: from localhost ([127.0.0.1]:39578 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v8gE3-0003UT-CO
for submit <at> debbugs.gnu.org; Tue, 14 Oct 2025 10:42:08 -0400
Received: from lists.gnu.org ([2001:470:142::17]:36902)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <robert.brown@HIDDEN>)
id 1v8gDw-0003TA-6h
for submit <at> debbugs.gnu.org; Tue, 14 Oct 2025 10:42:02 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <robert.brown@HIDDEN>)
id 1v8gDo-0007WP-EL
for bug-gnu-emacs@HIDDEN; Tue, 14 Oct 2025 10:41:52 -0400
Received: from mail-pg1-x52a.google.com ([2607:f8b0:4864:20::52a])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from <robert.brown@HIDDEN>)
id 1v8gDi-0001DB-Vm
for bug-gnu-emacs@HIDDEN; Tue, 14 Oct 2025 10:41:51 -0400
Received: by mail-pg1-x52a.google.com with SMTP id
41be03b00d2f7-b4755f37c3eso4747946a12.3
for <bug-gnu-emacs@HIDDEN>; Tue, 14 Oct 2025 07:41:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1760452901; x=1761057701; darn=gnu.org;
h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
:date:message-id:reply-to;
bh=kpzrldGqCA9RmfWHpn3P/UTZjGr/Rx8/xO1L0oXWjsA=;
b=EbQQaOXIHEIDv4Jp5vqg8aamtLayecVWQ1mlCFlMJJBN405wq7JLrylJH8EvmjgYk6
153YU9wEy0eY9/bpxc/NgJ6PQWoivIthFSwN1qpAJH3oc7y+V1n9fT/4w06hwSTcd7SQ
5tF8O8adIS8RP5dk/2VWdgy8sSmAqGGIV6g5G+GHwTnVfTxqqPYo+xuJ01xwAMTf7jzE
+BNCylNp18HYNSEoSEu1C+iQFAfwlnv+lB8Y8Hm78PE/VmnL6Nnq54Z8D0h6qA379OyN
n1kPv8EzeqSkHeUPR7VhIB9VASyaJ4G/k9VM2ZFzNHMRXvi6JWkFt1m8D6grHExRGGeo
gy7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1760452901; x=1761057701;
h=to:subject:message-id:date:from:mime-version:x-gm-message-state
:from:to:cc:subject:date:message-id:reply-to;
bh=kpzrldGqCA9RmfWHpn3P/UTZjGr/Rx8/xO1L0oXWjsA=;
b=LyK37vWyhQMnd6gNCqfNDzQlGgUGWl8y+z6BziId5HSBtDuwr9MMJSZ2hBYu1Irgwa
xkLQd/uGPP/C57cBUv67Rt7R981ozujn8CLrt2l7j1d6BUB/BWDVCjWUwJVh5cgOhq2n
aYoHfqrvTWzWvJWNY8pITqw9b4iH0solUo2IWGFvmiW8YXR6Bg5cySmt/n5dii3rO93w
V8vTkMUgwibgkzLWVT+/E4wS4BRU8/54wpiErR1nLpnO2QLXPVdayARAArXc4pWlpPlq
ZxOeVeEI8pNvhnT9ZDW+kdqR9EiX8jO4BAi9nPReAYzel9WoLBqm1amS+HKHa2Z+XT4i
Qyow==
X-Gm-Message-State: AOJu0YwzIbvoDMgyk8B7McRpr8qncUWpll+gBFxcPZORYLNcQvpcuyX1
6SlxFeIXW/HpgfHEe0AEfQYBC2hgYRm+2HX8argVf7oLXq9rAUnSoJaAPiQb9ZWeDM0MgmYKpSK
rMM23Itqo07eGJW3VyjBhkJjDHkS2gcuusfAt
X-Gm-Gg: ASbGncu4Wl23qKsjRCZucgL4Bmv9Q3ZF05ESsdhzBoXSfEztCfVS+nvECTgrHI59ETk
S/N1UUGalykuBNdBKRMB46ClCjzHhMTlzUWNjl9zMpnYW5FB33s2kBfgfTOrIBi5u4x4Z2m+hnU
/3h9I3PsYR4ZuflN4hyCmNMRVx9USy1S0VMfNRw5XkamiIvOhYk1ui5jlfMkPY1pblWfSxVbHt/
22z4YoexGK/IcoVBe9dTdVUcQ==
X-Google-Smtp-Source: AGHT+IEM/APP/dFbi51GXkYlGK1hSjKRG+swmwxdjsjDEHAK6YqF0fXiaQE+xOuKwnTHtsxD8xq/pEiCFoWh6xgGdR4=
X-Received: by 2002:a17:902:ce0d:b0:26b:da03:60db with SMTP id
d9443c01a7336-29027373dabmr351660415ad.13.1760452901084; Tue, 14 Oct 2025
07:41:41 -0700 (PDT)
MIME-Version: 1.0
From: Robert Brown <robert.brown@HIDDEN>
Date: Tue, 14 Oct 2025 10:41:29 -0400
X-Gm-Features: AS18NWCJmrChxouP-ycjT0lrhijf0NW2Vtn7tLVMy0dE4eOf_0Vln8rdHGRzi9o
Message-ID: <CAPNkkpnvn4D=wwbvSnLhh0qH3GZfAVb1bijnsE-UKkPwpXGgKw@HIDDEN>
Subject: 30.1; c-ts-mode wrong face for variable assignments
To: bug-gnu-emacs@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-Debbugs-Envelope-To: submit
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' for<br>=C2=A0 =C2=A0 ;; inspiration.<br>=C2=A0 =
=C2=A0 '((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 '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'configure --without-x<br>=C2=A0--prefix=3D/home/=
brown/local/software/package/emacs-30.1'<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--
Robert Brown <robert.brown@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#79623; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.