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

[Dmitry Gutov]

On 28/03/2023 14:32, Eli Zaretskii wrote:
> > Date: Tue, 28 Mar 2023 02:06:17 +0300
> > Cc: wkirschbaum@gmail.com, casouri@gmail.com, 62333@debbugs.gnu.org
> > From: Dmitry Gutov <dgutov@yandex.ru>
> >
> > On 27/03/2023 16:39, Eli Zaretskii wrote:
> > > > Date: Mon, 27 Mar 2023 08:24:42 +0000
> > > > From: Gregory Heytings<gregory@heytings.org>
> > > > cc: Eli Zaretskii<eliz@gnu.org>,wkirschbaum@gmail.com,casouri@gmail.com,
> > > >       62333@debbugs.gnu.org
> > > >
> > > > > > Which is a fragile, semi-broken means, as we all know.
> > > > > What is a broken mess, is user-level narrowing. And how the downstream
> > > > > code can never guess the purpose the narrowing was applied for.
> > > > Note that this is what labeled narrowings attempts to solve.
> > > Labeled narrowing cannot solve this because it does nothing to
> > > alleviate the problems with user-defined narrowing.  So if the user
> > > narrows the buffer, we cannot do anything to safely widen in the
> > > general case, and labeled narrowing cannot help us.
> >
> > 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?

> > judging by regular user requests for make this or that command
> > ignore user-level narrowing, it seems like "purely visual" should be the
> > default interpretation.
>
> I think you base your judgment on feedback from users who are not used
> to take advantage of narrowing in editing.  I think most young people
> aren't, since this feature is more-or-less unique to Emacs.

Either narrowing should be used to change lexical/grammatical/etc 
context, or it should not. Do we have any documentation that says one or 
the other way? That should affect how Lisp code deals with narrowing -- 
which interactive functions should widen, and so on.