GNU bug report logs -
#64818
30.0.50; c++-ts-mode highlight does not work
Previous Next
Full log
Message #37 received at 64818 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Theodor Thornhill <theo <at> thornhill.no>
>> Cc: 64818 <at> debbugs.gnu.org, dianchengwang <at> gmail.com
>> Date: Mon, 24 Jul 2023 19:13:07 +0200
>>
>> Eli Zaretskii <eliz <at> 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
This bug report was last modified 253 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.