GNU bug report logs - #64818
30.0.50; c++-ts-mode highlight does not work

Previous Next

Package: emacs;

Reported by: Wang Diancheng <dianchengwang <at> gmail.com>

Date: Mon, 24 Jul 2023 04:46:01 UTC

Severity: normal

Merged with 64830

Found in versions 29.1, 30.0.50

Done: Yuan Fu <casouri <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: dianchengwang <at> gmail.com, casouri <at> gmail.com, 64818 <at> debbugs.gnu.org
Subject: Re: bug#64818: 30.0.50; c++-ts-mode highlight does not work
Date: Mon, 24 Jul 2023 21:08:48 +0300
> 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.

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




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.