GNU bug report logs - #71784
31.0.50; Inconsistent fontification for field_identifier in c++-ts-mode

Previous Next

Full log

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

From: Ergus <spacibba <at> aol.com>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 71784 <at> debbugs.gnu.org
Subject: Re: bug#71784: 31.0.50; Inconsistent fontification for
 field_identifier in c++-ts-mode
Date: Thu, 27 Jun 2024 16:33:54 +0200

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 <bug-gnu-emacs <at> gnu.org> 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.

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?

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

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

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

Thanks again,
Best
Ergus

Previous Next

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