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

[Eli Zaretskii]

> Date: Fri, 31 Mar 2023 15:46:58 +0300
> Cc: wkirschbaum@gmail.com, gregory@heytings.org, casouri@gmail.com,
>  62333@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> 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).

I disagree that narrowing for, say, searching should be interpreted
like that.

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

We agree about that, at least.