bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modific


From: Yuan Fu
Subject: bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly
Date: Mon, 5 Dec 2022 18:15:07 -0800


> On Dec 5, 2022, at 7:44 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: Yuan Fu <casouri@gmail.com>,  59693@debbugs.gnu.org,  miha@kamnitnik.top
>> Date: Mon, 05 Dec 2022 10:29:06 -0500
>> 
>>> Will this "hold water" vis-a-vis the expectations of various features that
>>> would like to use tree sitter related capabilities?  Regardless of your
>>> opinion on indirect buffers, many 3rd party packages and features use
>>> indirect buffers as the backbone of their implementation.  We don't
>>> currently have any alternatives to that, AFAIK.  So I'd expect a lot of
>>> disappointment if we declare that indirect buffers will not be supported by
>>> tree sitter as a matter of design decision.
>> 
>> I can't see why: a package that uses indirect buffers can just as well
>> run its tree-sitter parsers in the base buffer.
> 
> I thought about those multi-mode modes, or features that show the same
> buffer more than once with different modes.
> 
>>> Changing insdel.c to run stuff in base buffer could be a solution, but
>>> I don't feel we can make such changes on the release branch.
>> 
>> Agreed.
>> 
>>> But maybe we can do that now only for treesit.c functions.
>> 
>> Sounds OK to me, yes.
> 
> OK, thanks.  Yuan, will this work for you? can you show a patch along these
> lines?

That wouldn’t work, unfortunately. We need to update all the parsers in every 
indirect and base buffer, enforce all changes to happen in the base buffer 
doesn’t help with that: indirect buffers’ parsers would be out-of-sync.

I can think of two ways:

1. Only allow base buffer to have parsers, no change is needed for insdel.c, 
treesit_record_change can find the base buffer and update its parsers. We can 
ask indirect buffers to use their base buffer’s parser. Unless the base buffer 
is narrowed, I think it will work fine. 

I remember that there were a discussion along the lines of user-narrow vs 
low-level narrow, what was the outcome of that discussion?

2. The patch I sent earlier, which tracks indirect buffers so all the relevant 
buffer’s parser are updated at a buffer content change.

Yuan






reply via email to

[Prev in Thread] Current Thread [Next in Thread]