bug#67977: 30.0.50; tree-sitter: Emacs crashes when accessing treesit-nodes in a narrowed buffer

[Dmitry Gutov]

On 29/12/2023 09:00, Yuan Fu wrote:
> > On Dec 28, 2023, at 8:16 AM, Dmitry Gutov <dmitry@gutov.dev> wrote:
> >
> > On 28/12/2023 15:53, Eli Zaretskii wrote:
> > > > Date: Thu, 28 Dec 2023 13:44:43 +0200
> > > > Cc: Denis Zubarev<dvzubarev@yandex.ru>,67977@debbugs.gnu.org
> > > > From: Dmitry Gutov<dmitry@gutov.dev>
> > > >
> > > > > > Could font-lock-dont-widen help, perhaps?
> > > > > Yes. If font-lock doesn’t widen, then there wouldn’t be back-and-forth reparses.
> > > > But then treesit major modes will be affected by user narrowing (e.g. if
> > > > the user narrowed to inside the string, the buffer won't be highlighted
> > > > as a string).
> > > Why is that a problem?  When the user narrows the buffer, the part
> > > outside the narrowing doesn't exist as far as Emacs is concerned.
> >
> > That's not how it works in most major modes, at least since the introduction of 
> > font-lock-dont-widen 20 years ago.
> >
> > Like its docstring says, the exceptions were supposed to be weird modes like 
> > RMAIL and Info which use narrowing for their own purposes (that seems buggy in 
> > Info's case, when 'C-x n w' breaks the intended display right away). But even 
> > Info-mode doesn't actually change font-lock-dont-widen, actually, because the 
> > apparent behavior would be the same. But it could.
> >
> > I don't have a personal stake in this (I never use narrowing interactively). 
> > But maybe you'll want to make a poll, to ask the users that do.
>
> I guess that depends on how you view narrowing, I assume most of the time the 
> user considers narrowing to be something that narrows the view to a region, 
> rather than effectively removing the rest of the buffer. IIRC We’ve had 
> discussions on adding “types” to narrows but to no conclusion.

Indeed.

> Anyway, if the reparse caused by narrowing prove to be problematic, I can 
> implement the optimization I mentioned earlier, where we use two parsers, one 
> for when buffer is widened and one for when buffer is narrowed. This will be in 
> C and is transparent to lisp.

This definitely can work, but perhaps we should examine concrete use 
cases first. It could be that the caller would want the full parse tree 
available anyway, when the view was narrowed interactively by the user.

Then the actual advice from us would be to (save-restriction (widen 
...)) anyway, and the second parse tree would stay mostly unused.

It's a good thing to have fixed the crash, though, so the developers can 
try it both ways and decide what's best for them.