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

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 76398 <at> debbugs.gnu.org, Vincenzo Pupillo <v.pupillo <at> gmail.com>
Subject: bug#76398: treesit-aggregated-outline-predicate
Date: Tue, 11 Mar 2025 20:18:32 +0200

close 76398 31.0.50
thanks

>>> Combine with your reply above, it seems we need some information attached
>>> to the ranges (with either overlay or text property), rather than to the
>>> parser. Is that right?
>> 
>> Maybe.  One of two needs I have discovered so far is the ability
>> to find the next/previous range boundary.
>
> I pushed some changes. Now this should be doable by searching for overlays
> boundaries. Both local and non-local parsers now have an overlay that spans
> the range they’re in. In the case of non-local parsers, each range it
> parses gets an overlay. You can search for the comment that’s marked with
> (ref:local-parser-overlay) in treesit.el to see the properties I put on the
> overlays.

Thanks!  Searching for the next overlay now works nicely,
so pushed the changes to 'treesit-outline-search'.

>>> When updating ranges, we can mark the ranges covered
>>> by each embed parser, and perhaps link the text prop or overlay to the
>>> “parent node”.
>> 
>> The ability to find the parent node of the range is another need.
>
> I think your use-case is to continue searching upwards across parser
> boundary, right?  I wonder if having access to the parent parser is
> enough?  Because once you know the parser, you can just get the
> node-at-point.

Yes, having access to the parent parser is enough,
and everything works with the 'treesit-host-parser' overlay
by finding the parent parser node with 'treesit-node-at',
so pushed the changes to 'treesit-outline-level' as well.

Previous Next

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