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

From: Eli Zaretskii <[email-masked]>
Date: Fri, 31 Mar 2023 16:06:36 +0300

> Date: Fri, 31 Mar 2023 15:46:58 +0300
> Cc: [email-masked], [email-masked], [email-masked],
>  [email-masked]
> From: Dmitry Gutov <[email-masked]>
> 
> 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.