GNU bug report logs - #62333
30.0.50; Issue with tree-sitter syntax tree during certain changes

Previous Next

Package: emacs;

Reported by: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>

Date: Tue, 21 Mar 2023 14:15:01 UTC

Severity: normal

Found in version 30.0.50

Full log


Message #83 received at 62333 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: wkirschbaum <at> gmail.com, casouri <at> gmail.com, 62333 <at> debbugs.gnu.org
Subject: Re: bug#62333: 30.0.50; Issue with tree-sitter syntax tree during
 certain changes
Date: Sun, 26 Mar 2023 00:57:22 +0200
On 25/03/2023 19:40, Eli Zaretskii wrote:
>> Date: Sat, 25 Mar 2023 19:05:13 +0200
>> Cc: wkirschbaum <at> gmail.com, casouri <at> gmail.com, 62333 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>> On 25/03/2023 18:24, Eli Zaretskii wrote:
>>>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>>> Cc: "wkirschbaum <at> gmail.com" <wkirschbaum <at> gmail.com>,
>>>> 	"casouri <at> gmail.com" <casouri <at> gmail.com>,
>>>> 	"62333 <at> debbugs.gnu.org" <62333 <at> debbugs.gnu.org>
>>>> Date: Sat, 25 Mar 2023 19:03:45 +0300
>>>>
>>>>     But if the mmm framework narrowed the region to the current mode's
>>>>     block, widening will force tree-sitter to parse the whole buffer.
>>>>
>>>>    No, because such a mode mode should already make sure this doesn't
>>>>    happen.
>>>>
>>>> How?
>>>
>>> The same way it makes sure a given parser is used only on the portion
>>> of the buffer where the corresponding language is used.
>>
>> It uses narrowing.
> 
> How does that work with features such as font-lock, which do widen?

Using font-lock-dont-widen.

We've had this discussion several times over by now. Should it be 
documented somewhere?

> Anyway, isn't this discussion a bit premature, as no TS mode has been
> used with the mmm framework yet?

There is no reason to assume that: the combinations of modes are just a 
matter of user configuration. And so far it should be working okay.

> Because when they do, I imagine they
> will need to invent some mechanism that is more reliable than
> narrowing.

"They" is me. I'd rather the general mechanism keeps working, or we come 
up with another general mechanism that is a better substitute, before 
breaking this one.

And anyway, I like I mentioned, this will break this common pattern as well:

  (save-restriction
    (narrow-to-region ... some-limit-position)
    (forward-sexp))

I've used it in ruby-syntax-propertize-percent-literal, for example. 
Except with 'forward-list' rather than 'forward-sexp', but others can 
use the latter.




This bug report was last modified 2 years and 77 days ago.

Previous Next


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