Subject: Re: bug#59426: 29.0.50; [tree-sitter] Some functions exceed maximum recursion limit

From: Yuan Fu <[email-masked]>
Date: Thu, 24 Nov 2022 11:25:58 -0800

> On Nov 24, 2022, at 2:24 AM, Mattias Engdegård <[email-masked]> wrote:
> 
> 24 nov. 2022 kl. 10.17 skrev Yuan Fu <[email-masked]>:
> 
>> Does it worth the complexity tho? We only need a stack if we want to support this scenario, in which case tree-sitter has a wrong parse tree. Instead of spending the time and resource to go down that deep tree, it’s better to fail early, and let the user decide to either give up on weird files, or try some other approximation.
>> 
>> It’s too early to tell if being able to go down arbitrarily deep into a deep tree is useful. The only use of traversing the whole tree right now is to generate the imenu indexes, which don’t really need to go down more than 10 levels, since most defun nodes we are interested in are either top-level or near top-level.
> 
> You may very well be right about that.

That brings us back to the original question: what limit should we use? I suggest we use a smaller number since normal tree should never be very tall. Running the following code tells me the height of the tree for xdisp.c is 30:

(defun measure-height (node)
  (let ((children (treesit-node-children node t)))
    (if children
        (1+ (apply #'max (mapcar #'measure-height children)))
      1)))
;; In xdisp.c:
(measure-height (treesit-buffer-root-node))

Maybe a limit in the range of hundreds or thousands? 800?

> 
>> So I’d prefer we keep it simple and have a hard limit for now. If we later find that a stack is favorable we can always add it in.
> 
> That sounds good. Maybe the #line snag in the packet-rrc.c example should be reported upstream?

I stole your sample and opened an issue on their GitHub repo: 

https://github.com/tree-sitter/tree-sitter-c/issues/118

Yuan