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

[Eli Zaretskii]

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

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