From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.bugs Subject: bug#71784: 31.0.50; Inconsistent fontification for field_identifier in c++-ts-mode Date: Tue, 16 Jul 2024 23:27:37 -0700 Message-ID: References: <87pls394h0.fsf.ref@aol.com> <87pls394h0.fsf@aol.com> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10478"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 71784@debbugs.gnu.org To: Ergus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jul 17 08:29:22 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sTyAE-0002VN-A7 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 17 Jul 2024 08:29:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sTy9u-0006ZO-I5; Wed, 17 Jul 2024 02:29:02 -0400 Original-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 ) id 1sTy9r-0006NA-Nv for bug-gnu-emacs@gnu.org; Wed, 17 Jul 2024 02:28:59 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sTy9r-0002Vk-G0 for bug-gnu-emacs@gnu.org; Wed, 17 Jul 2024 02:28:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sTy9u-0004Wt-E7 for bug-gnu-emacs@gnu.org; Wed, 17 Jul 2024 02:29:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 17 Jul 2024 06:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71784 X-GNU-PR-Package: emacs Original-Received: via spool by 71784-submit@debbugs.gnu.org id=B71784.172119773717400 (code B ref 71784); Wed, 17 Jul 2024 06:29:02 +0000 Original-Received: (at 71784) by debbugs.gnu.org; 17 Jul 2024 06:28:57 +0000 Original-Received: from localhost ([127.0.0.1]:34943 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sTy9o-0004WZ-Uf for submit@debbugs.gnu.org; Wed, 17 Jul 2024 02:28:57 -0400 Original-Received: from mail-pl1-f171.google.com ([209.85.214.171]:55748) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sTy9n-0004WR-1N for 71784@debbugs.gnu.org; Wed, 17 Jul 2024 02:28:55 -0400 Original-Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-1fc4fcbb131so1771695ad.3 for <71784@debbugs.gnu.org>; Tue, 16 Jul 2024 23:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721197671; x=1721802471; 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=tElpCzRKfzchWL1iJb7ytioDSpNnKF+mvqHo0Z8Ffj0=; b=HZmVITA11i1Y3J9BsIcZrkfPNIP1+mgNsHJzU9cnI5Wcjsjww7D3HSKDgUAP24jOtn Y3WiiCcmek9xfG6DhIYlXQwPr5XSzUKTEAaIM+oxXqmkp/8FilZQsvwlwheuwJYO3QLX M3fnQ94pV2rJORO+LoQRGXG2IAday1sKyF0FtJEMez+A1XFG5urUetnkDEaofQ6R4NbQ QgL3up9BSKnpnx9Ekme8liJ1CUWSYCjoTHYR3ci1EeIk3Zv3S8EbHNd7F2VdnvOP5B58 sWH5dBdiD4+cCEjkIE4qoTKNcTmc3BzQJUMP+2A18aWBQFLnLjyr08XWNd1vWUToHSfR harg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721197671; x=1721802471; 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=tElpCzRKfzchWL1iJb7ytioDSpNnKF+mvqHo0Z8Ffj0=; b=NMg1bnKGlYKm0QqBlMFs6N55bWGkefeBZRZaN9Se5qaK7+MfvMAsvEEaRkKR116rCx BGnlurG7vZdoHkTmPMjOUTKW5Au3TeM3r43Kxc1Wlpd/DyfsayQ6WdzaqK3sGJvmQPcr 38PVAIFWAVGoGMk0bIy8zkUy28i8iQ4ondTeNCjRxwo4BKYYjGWnnZ0wu/vOnE9oaxIK vC/HPMxP3diL6tTQuY+qJy0jGtcihpcIL8kz5P5ruZeTK0+xm+JMGTuVt/w6om+/Rpv+ GJxBqFah+EGO9O2DfpXM99PSXNQt5ZsVAzcxn2NYK55q9hUCEr8xZoiBuiFtgoTDB8Ji OYpg== X-Gm-Message-State: AOJu0Ywnkg/LPPcSgM1TDScCT6zhYqly3+NHj0D1KG3d/NoWI8i8TNY0 QwLaN5ctzPKpxtK+tVKl90FQtHRUvFxxBqpOplBAn5tOmbZ1lP3VL69Jaw== X-Google-Smtp-Source: AGHT+IFWzT0WwaMMoIluycBo10EwXR/4i5Cl8e0pHMMvNGVlXrzasIPyBV3uD2X4pURugH7VUz3utQ== X-Received: by 2002:a05:6a21:33a6:b0:1c0:e1ed:1e9 with SMTP id adf61e73a8af0-1c3fdcbff8emr979777637.6.1721197669572; Tue, 16 Jul 2024 23:27:49 -0700 (PDT) Original-Received: from smtpclient.apple ([2601:646:8f81:6120:c931:36dd:b6ff:8bfc]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-70b81972f56sm7163349b3a.84.2024.07.16.23.27.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jul 2024 23:27:49 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.3774.600.62) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:288911 Archived-At: > On Jun 27, 2024, at 7:33=E2=80=AFAM, Ergus wrote: >=20 > Hi Yuan: >=20 > Very thanks for replying >=20 > On Thu, Jun 27, 2024 at 12:16:13AM GMT, Yuan Fu wrote: >>=20 >>=20 >>> On Jun 26, 2024, at 7:13=E2=80=AFAM, Ergus via Bug reports for GNU = Emacs, the Swiss army knife of text editors = wrote: >>>=20 >>>=20 >>> Hi: >>>=20 >>> Using the c++-ts-mode I found that there is some inconsistent >>> fontification for the `fields_identifier`: >>>=20 >>> See the fontification in this example with `emacs -Q`. >>>=20 >>> ```test.cpp >>>=20 >>> std::string key; >>> bool inserted; >>>=20 >>> struct name_t { >>> std::string key; >>> bool inserted; >>> }; >>>=20 >>> name_t keys =3D {"aaa", true}; >>>=20 >>> keys.inserted =3D false; >>> bool a =3D keys.inserted; >>> ``` >>>=20 >>> 1. The `keys.inserted` values are shown differently before or after = the >>> =3D (the inserted word is fontified is some cases, but not in all) >>=20 >> What=E2=80=99s the value of treesit-font-lock-level for you? If = it=E2=80=99s 4, they >> should be fontified the same. On level 3, only LHS is fontified. >>=20 > You are right; it is 3 in my system. >=20 > However I would expect that treesit-font-lock-level will be equivalent > somehow to using font-lock-maximum-decoration with similar value. It is, level 3 for treesit-font-lock generally try to be equivalent to = the existing major modes; and level 4 adds additional fontification = that=E2=80=99s usually only possible with tree-sitter. At least that=E2=80= =99s the suggestion, I don=E2=80=99t know if major mode writers out = there are following this suggestion. >=20 > I think it is confusing having two different fontifications for the = same > variable due to their position. The colors are supposed to be a sort = of > hint or help for the programmer eyes; not just a decoration right? True, but: Highlighting all occurrences of properties/fields is a bit = too much highlight IMO, and it isn=E2=80=99t done in most major modes, = so I put it on level 4. On the default font-lock level, it=E2=80=99s = helpful to highlight variable assignment/definition. You=E2=80=99re free = to enable the property feature and disable assignment feature, which = should get you what you want; but for the default, I think the current = configuration is more appropriate. >=20 >>>=20 >>> 2. The variable names are fontified differently outside or >>> inside the struct. >>=20 >> I mean, the =E2=80=9Cvariable name=E2=80=9D inside a structure is a = field, not a >> variable, so it makes sense that they are fontified >> differently. Variable has font-lock-variable-name-face, field has >> font-lock-field-name-face. Also variable and field face are the same = in >> the default theme, so they should look the same nevertheless. >>=20 > Probably what annoys me is the difference with the previous behavior = in > this case. A field is also a variable in some sense for C++. There is > not much difference with a variable in a namespace or a static = variable > in a class...=20 > Does it makes sense not to colorize these "field" and LHS on level 3 > (like it used to be in c++-mode)? But put the new fontifications all > together in level 4? In that way everything will be fontified in level = 4 > and will become immediately consistent. I=E2=80=99m sure this makes sense to you, but the nature of these things = is that different people has different senses, so what makes sense to = you might not make sense to others, and vice versa. To me, highlighting = assignments is useful, and I don=E2=80=99t really notice the mismatch = that bothers you. Unless many people complain about it, I don=E2=80=99t = want to change the default behavior because of the reason I mentioned = earlier. Again, this thing is highly personal and I don=E2=80=99t think = there=E2=80=99s a fit-all solution. >>>=20 >>> 3. The escape sequence (\t) is fontified differently to the rest of = the >>> text inside the string. I don't know if that is intentional or not. = If >>> it is intentional, just ignore this comment. >>=20 >> Yeah it=E2=80=99s intentional. >>=20 > Ok, good! Again, (just as a suggestion) it makes sense to move this = new > fontification to level 4 as well? IIRC many major modes do highlight escapes, so I put it on level 3. >>>=20 >>> The inconsistencies 1 and 2 are not only different to c++-mode but = they >>> are semantically incorrect. >>=20 >> Yuan >=20 >=20 > Just to mention: I am not wondering about the match/compatibility with > c++-mode. I am only concerned about the semantic coherence of the > fontification; which is supposed to be somehow helpful, not confusing. I definitely appreciate the perspective you provided; however, unless = there are enough people cares to complain about this, I don=E2=80=99t = want to change the defaults. Plus it=E2=80=99s quite easy to remove: = just disable the assignment feature. Yuan=