bug#71784: 31.0.50; Inconsistent fontification for field_identifier in c++-ts-mode

[Eli Zaretskii <eliz@gnu.org>]

tags 71784 wontfix
close 71784
thanks

> Cc: 71784@debbugs.gnu.org
> From: Yuan Fu <casouri@gmail.com>
> Date: Tue, 16 Jul 2024 23:27:37 -0700
> 
> 
> 
> > On Jun 27, 2024, at 7:33 AM, Ergus <spacibba@aol.com> 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 <bug-gnu-emacs@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.
> 
> 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.