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

Previous Next

Full log

Message #25 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: 64818 <at> debbugs.gnu.org, dianchengwang <at> gmail.com, casouri <at> gmail.com
Subject: Re: bug#64818: 30.0.50; c++-ts-mode highlight does not work
Date: Mon, 24 Jul 2023 19:08:44 +0300

> From: Theodor Thornhill <theo <at> thornhill.no>
> Cc: dianchengwang <at> gmail.com, casouri <at> gmail.com, 64818 <at> debbugs.gnu.org
> Date: Mon, 24 Jul 2023 16:31:41 +0200
> 
> >> Error during redisplay: (jit-lock-function 14) signaled (treesit-query-error "Node type error at" 99 "(true)
> >> @font-lock-constant-face (false) @font-lock-constant-face (null) @font-lock-constant-face (nullptr)
> >> @font-lock-constant-face" "Debug the query with `treesit-query-validate'") [2 times] 
> 
> 
> Yep, nullptr was changed from named node to unnamed node last week [0].
> 
> I think we can live without a compat change and only target the node
> as a normal keyword. I'll commit the fix if it is simple enough (the
> simplest is just to remove the node altogether),
> otherwise I'll send a patch for review. Sounds ok?

I'd prefer to see the patch.  Also, can you tell more about the effect
of the change you propose ("remove the node")?

More generally, I'm a bit worried by such incompatible changes in the
grammar libraries.  The developers must understand that they break
users of tree-sitter, right?  So why are they making such incompatible
changes?  And how do other editors cope with such changes, for example
this one?

I'm asking these questions because perhaps we are doing something we
shouldn't, or not doing something we should.  I don't think we can
tell our users to use only a specific commit from the grammar
libraries' repositories: a significant portion of Emacs users tend to
switch to a new version many moons after the release (e.g., I see
reports from people who only now upgrade from Emacs 27 to Emacs 28,
more than a year since Emacs 28 was released).  So a grammar library
which was the current one on the release date will be hopelessly
outdated by the time some users will switch to that Emacs version.

So we must look for some more robust way, if it exists.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.