GNU bug report logs - #59415
29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file

Previous Next

Full log

View this message in rfc822 format

From: Yuan Fu <casouri <at> gmail.com>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: eliz <at> gnu.org, 59415 <at> debbugs.gnu.org
Subject: bug#59415: 29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file
Date: Sun, 20 Nov 2022 13:27:04 -0800

> On Nov 20, 2022, at 1:09 PM, Theodor Thornhill <theo <at> thornhill.no> wrote:
> 
>>> This diff fixes the font-lock issues:
>>> 
>>> diff --git a/lisp/treesit.el b/lisp/treesit.el
>>> index 674c984dfe..0f84d8b83e 100644
>>> --- a/lisp/treesit.el
>>> +++ b/lisp/treesit.el
>>> @@ -774,12 +774,12 @@ treesit-font-lock-fontify-region
>>>      ;; will give you that quote node.  We want to capture the string
>>>      ;; and apply string face to it, but querying on the quote node
>>>      ;; will not give us the string node.
>>> -      (when-let ((root (treesit-buffer-root-node language))
>>> +      (when-let (
>>>                 ;; Only activate if ENABLE flag is t.
>>>                 (activate (eq t enable)))
>>>        (ignore activate)
>>>        (let ((captures (treesit-query-capture
>>> -                         root query start end))
>>> +                         (treesit-node-on start end) query start end))
>>>              (inhibit-point-motion-hooks t))
>>>          (with-silent-modifications
>>>            (dolist (capture captures)
>>> 
>>> 
>>> However, the comment right above makes a case for why we should have
>>> this.  BUT, is this still relevant, Yuan, after the changes in treesit
>>> reporting what has changed etc?  What exact case is that an issue?  And
>>> is it more severe than the behavior this bug is exhibiting?
>> 
>> The case described by the comment is still relevant. With this patch,
>> the quote described in that case still wouldn’t be fontified. We can
>> use some heuristic to get a node “large enough” and not the root
>> node. Eg, find some top-level node. That should make query-capture
>> much faster.
>> 
> 
> I appreciate the explanation.  I think getting the root is a bit
> excessive.  I got the same results as you in the capture.  Maybe reuse
> the treesit-defun-type-regexp, and default to root if none found?

I tried the "top-level node” approach, and it didn’t help in package-rrc.c: the top-level node (a function definition) is still too large (spans 7680306-9936062). Since the case I described in the comment against using treesit-node-on is the exception rather than the norm, maybe we can go the other way around: use treesit-node-on first, and if the node seems too small (by some heuristic), enlarge it to some degree.

Yuan

Previous Next

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