bug#64818: 30.0.50; c++-ts-mode highlight does not work

[Theodor Thornhill]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: 64818@debbugs.gnu.org, dianchengwang@gmail.com
>> Date: Mon, 24 Jul 2023 19:13:07 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Can you show the patch?
>> >
>> 
>> diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el
>> index 7f4f6f11387..98797bf3ce7 100644
>> --- a/lisp/progmodes/c-ts-mode.el
>> +++ b/lisp/progmodes/c-ts-mode.el
>> @@ -574,9 +574,7 @@ c-ts-mode--font-lock-settings
>>     :feature 'constant
>>     `((true) @font-lock-constant-face
>>       (false) @font-lock-constant-face
>> -     (null) @font-lock-constant-face
>> -     ,@(when (eq mode 'cpp)
>> -         '((nullptr) @font-lock-constant-face)))
>> +     (null) @font-lock-constant-face)
>>  
>>     :language mode
>>     :feature 'keyword
>
> Thanks, please install this on the emacs-29 branch.
>

Now done

>> > What about catching errors inside treesit.c or treesit.el, so that the
>> > features that disappeared and queries that fail don't fail the entire
>> > font-lock?  Would that work, or at least make Emacs more robust in the
>> > face of such changes?
>> >
>> > Yuan, WDYT?
>> >
>> > (This more robust approach is certainly not for Emacs 29.1, even if we
>> > agree that it's a good idea.)
>> 
>> I'll defer that to Yuan, as I'm not 100% on where such errors can be
>> caught, and if it can make the parser enter some state it shouldn't be
>> in.
>
> AFAIU, it isn't the parser that signaled an error, it's our code which
> queried tree-sitter about a node that doesn't exist.

True, my bad.

Theo