GNU bug report logs - #76398
treesit-aggregated-outline-predicate

Previous Next

Full log

View this message in rfc822 format

From: Yuan Fu <casouri <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 76398 <at> debbugs.gnu.org, v.pupillo <at> gmail.com
Subject: bug#76398: treesit-aggregated-outline-predicate
Date: Fri, 21 Feb 2025 22:12:59 -0800

> On Feb 20, 2025, at 11:56 PM, Juri Linkov <juri <at> linkov.net> wrote:
> 
>>> So this patch helps 'treesit-outline-search' to get out of the local parser
>>> to the primary parser to continue search for the next outline predicate.
>>> 
>>> 'treesit-outline-level' should do the same, but currently I can't find
>>> a suitable function to break out of embedded confinement
>>> and get the host node that contains the guest ranges.
>>> I mean that e.g. (treesit-parser-root-node (treesit-node-parser node))
>>> can get the root node of the local parser, but how to get its parent node
>>> in the primary parser?  It's understandable that treesit-node-parent
>>> doesn't go out of its parser.  But maybe there is another function?
>>> If such function doesn't exist, this is fine, then could find that
>>> node manually by calculating from treesit-parser-included-ranges.
>> 
>> Maybe we need two new primitives:
>> 
>>  (treesit-next-parser-boundary POS)
>>  (treesit-prev-parser-boundary POS)
> 
> Now pushed as 'treesit-closest-parser-boundary'.

Hold on, let’s not get ahead of ourselves. First of all, the name is not very descriptive IMO it actually finds range boundary, not parser boundary; and the docstring mentions local parser while the function itself doesn’t really involve local parsers—it just checks parser ranges. It can be used for getting out of local parsers, yes, but that’s a use-case, not what it does. So if we want to add this function to the public API set for tree-sitter, it needs a better docstring. (And at the moment I have doubt on its general usefulness.)

More over, is this even necessary? Why do we need to go over all the ranges for all the parsers to get out of a local parser? I thought we can just get the local parser and get it’s range?

>>  (treesit-upper-parser-node POS)
> 
> Addition of 'treesit-upper-parser-node' is underway that should
> be used in 'treesit-up-list' as well.

And if we need to get the “parent node” of a local parser, we can do it in much nicer ways. We can record the parent node when creating the local parser, by either adding a field to the parser object, or record it in a local database, or even just save it in the text property alongside the local parser. Let’s take some time and think of the best way to solve this. Whatever you have in mind, I suspect that it wouldn’t work if there are more than one layer of nesting of parsers, ie, what if you want to get out of a embedded (local) parser’s embedded parser?

On the same note, we actually need some proper tree structure for the primary parser - local parser relationship, because there can be more than one layer. What we currently have doesn’t handle this well (font-lock and indentation). It’s a real use case, someone requested for this for the Perl (or Haskell?) mode, and imagine a rust buffer embeds a markdown comment which embeds rust code examples. I bring this up because this tree structure would’ve solved your problem here as well, once we have it.

Yuan

Previous Next

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