From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#71784: 31.0.50; Inconsistent fontification for field_identifier in c++-ts-mode Date: Sun, 04 Aug 2024 10:13:55 +0300 Message-ID: <86ikwgu5e4.fsf@gnu.org> References: <87pls394h0.fsf.ref@aol.com> <87pls394h0.fsf@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10275"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 71784@debbugs.gnu.org, spacibba@aol.com To: Yuan Fu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Aug 04 09:15:21 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 1saVSa-0002V9-Kl for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 04 Aug 2024 09:15:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1saVSG-0001N6-Uh; Sun, 04 Aug 2024 03:15:05 -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 1saVS2-0001MP-Rz for bug-gnu-emacs@gnu.org; Sun, 04 Aug 2024 03:14:47 -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 1saVRy-00017b-5X for bug-gnu-emacs@gnu.org; Sun, 04 Aug 2024 03:14:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-version:References:In-Reply-To:From:Date:To:Subject; bh=8i4VQsWq+/SFBeVt+yTY707LGxNgbY0GPrP5jvjlC58=; b=YPLCExaRLc0i/TE6KdKxlL2ppVwofucQoYrBiUQ86tkxiVZbRVy9wZDiXz1A/f2w/NDtcn2qtCZYyRJKzFEqyhBRzeqvMjtR22BwvFZOvvfm/Eu1a/xEwU0MHbMIhvz0cJaaRqMHJuu4Zm1TSmxd1qEwB3wUGMxqUR7A20DU7IPLoyDKZyQHS59tXNDwLtABxYVN4UBRdMNi6lcVu5eL5UwBahzy///Ab78yW6AQ1rz36esVDhfysCWdwrYIRRqjM6qpIitswuWrt1iGzy7q3MKbCEnrGsPadwAAl8yX0es6i2BsIZR5w7BcXl5ErzeCtJzh4Nn7/N1V7Ef5kl+G0w==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1saVSI-0002vu-R7 for bug-gnu-emacs@gnu.org; Sun, 04 Aug 2024 03:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Aug 2024 07:15: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.172275566611151 (code B ref 71784); Sun, 04 Aug 2024 07:15:02 +0000 Original-Received: (at 71784) by debbugs.gnu.org; 4 Aug 2024 07:14:26 +0000 Original-Received: from localhost ([127.0.0.1]:55302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1saVRh-0002tk-Hv for submit@debbugs.gnu.org; Sun, 04 Aug 2024 03:14:26 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36306) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1saVRg-0002tM-9s; Sun, 04 Aug 2024 03:14:24 -0400 Original-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 ) id 1saVRG-00013v-8l; Sun, 04 Aug 2024 03:13:58 -0400 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=8i4VQsWq+/SFBeVt+yTY707LGxNgbY0GPrP5jvjlC58=; b=p3qKcqdmyisIQcAPZbSg /RZVWvKe09gQ2yNrIemF6Z2eUwHL8FQ5uaLfM+RrbVEn3gIb7j0F5p6uG9mT+xifxtCJ4Pq0ZZEor 70iC/2oPW5sTIc5e/I0jYE/0ktj0dQkcVHxGEsNoVFfPKL33ZND2MVR1XRX/WqzEn/PDR1eLm2nsh iOvVzUz1zRn774aCLtWcUWnP0PbWtqofaDO/Zw647aq8EkbcnN9AU8aRCb7QKF2n1Fe0L7jL4Kkrb OIdAQgR+lLcB1JYKuE0mdmK54n52oT3jVT/ZElEiOm4ww6P2uMiwweK7JW+q+1vJt3RHjg4kWKVgA fZDW3ftMv11rAA==; In-Reply-To: (message from Yuan Fu on Tue, 16 Jul 2024 23:27:37 -0700) 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:289706 Archived-At: tags 71784 wontfix close 71784 thanks > Cc: 71784@debbugs.gnu.org > From: Yuan Fu > Date: Tue, 16 Jul 2024 23:27:37 -0700 > > > > > On Jun 27, 2024, at 7:33 AM, Ergus wrote: > > > > Hi Yuan: > > > > Very thanks for replying > > > > On Thu, Jun 27, 2024 at 12:16:13AM GMT, Yuan Fu wrote: > >> > >> > >>> On Jun 26, 2024, at 7:13 AM, Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: > >>> > >>> > >>> Hi: > >>> > >>> Using the c++-ts-mode I found that there is some inconsistent > >>> fontification for the `fields_identifier`: > >>> > >>> See the fontification in this example with `emacs -Q`. > >>> > >>> ```test.cpp > >>> > >>> std::string key; > >>> bool inserted; > >>> > >>> struct name_t { > >>> std::string key; > >>> bool inserted; > >>> }; > >>> > >>> name_t keys = {"aaa", true}; > >>> > >>> keys.inserted = false; > >>> bool a = keys.inserted; > >>> ``` > >>> > >>> 1. The `keys.inserted` values are shown differently before or after the > >>> = (the inserted word is fontified is some cases, but not in all) > >> > >> What’s the value of treesit-font-lock-level for you? If it’s 4, they > >> should be fontified the same. On level 3, only LHS is fontified. > >> > > You are right; it is 3 in my system. > > > > 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’s usually only possible with tree-sitter. At least that’s the suggestion, I don’t know if major mode writers out there are following this suggestion. > > > > > 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’t done in most major modes, so I put it on level 4. On the default font-lock level, it’s helpful to highlight variable assignment/definition. You’re 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. > > > > >>> > >>> 2. The variable names are fontified differently outside or > >>> inside the struct. > >> > >> I mean, the “variable name” 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. > >> > > 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... > > 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’m 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’t really notice the mismatch that bothers you. Unless many people complain about it, I don’t want to change the default behavior because of the reason I mentioned earlier. Again, this thing is highly personal and I don’t think there’s a fit-all solution. > > >>> > >>> 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. > >> > >> Yeah it’s intentional. > >> > > 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. > > >>> > >>> The inconsistencies 1 and 2 are not only different to c++-mode but they > >>> are semantically incorrect. > >> > >> Yuan > > > > > > 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’t want to change the defaults. Plus it’s quite easy to remove: just disable the assignment feature. No further comments, so I think we don't want to make this change, and I'm therefore closing this bug. Thanks.