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

[Dmitry Gutov]

On 31/03/2023 09:19, Eli Zaretskii wrote:
> > 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.

Okay, let's rephrase that: instead of "visual effect", we can say it's 
for "visually hiding" parts of buffers. But not for changing their 
behaviors otherwise (e.g. changing syntax highlighting, etc).

In your other answer regarding the inside of a string, you seemed to 
have a different idea, though. Like, user narrowing would be able to 
affect all that stuff too.

> > > 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.

This subthread goes back to my complaint that commands don't know how to 
*interpret* the current narrowing, thus which effects it should have.

To repeat:

  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.