bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes

[Eli Zaretskii]

> Date: Fri, 31 Mar 2023 04:10:54 +0300
> Cc: wkirschbaum@gmail.com, gregory@heytings.org, casouri@gmail.com,
>  62333@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> On 29/03/2023 14:08, Eli Zaretskii wrote:
> >> Date: Wed, 29 Mar 2023 00:08:53 +0300
> >> Cc: wkirschbaum@gmail.com, gregory@heytings.org, casouri@gmail.com,
> >>   62333@debbugs.gnu.org
> >> From: Dmitry Gutov <dgutov@yandex.ru>
> >>
> >>>> Is that because we don't think the user level narrowing is done purely
> >>>> for visual effect?
> >>>
> >>> Indeed, it isn't always for visual effect.
> >>
> >> When isn't it? Is there a way to determine that from code?
> > 
> > I'm not sure I understand the question, but if I do, then narrowing to
> > prevent search functions
> 
> If we're talking about isearch, then that seems like a natural 
> consequence of visual effect (hiding the remainder of the buffer): even 
> if isearch highlighted those other hits, they would not be visible.

If you consider narrowing in this example to be "for visual effect",
then everything in Emacs is "for visual effect".  After all, Emacs is
a visual editor, showing the results of editing to the user at all
times.  But this POV makes this part of the discussion useless.

> > I was talking about user commands that narrow, so I'm not sure I
> > understand how documentation could help.  When the user types "C-x n n",
> > there's nothing Emacs can do except obey.
> 
> There is really only one main user command that narrows, and that's 
> narrow-to-region, bound to 'C-x n n'.

Any user command can narrow as part of its job.

> Simple example: if the beginning of the narrowed region falls inside a 
> (let's say multine) string, should the visible remainder of that string 
> continue to be highlighted as a string?

No.

> Or should the buffer contents after the string's closer now be
> highlighted as being inside a string?

Yes.