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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4