GNU bug report logs - #62333
30.0.50; Issue with tree-sitter syntax tree during certain changes

Previous Next

Full log

View this message in rfc822 format

From: Yuan Fu <casouri <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>, Gregory Heytings <gregory <at> heytings.org>, 62333 <at> debbugs.gnu.org
Subject: bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes
Date: Fri, 31 Mar 2023 11:43:49 -0700

> On Mar 31, 2023, at 5:46 AM, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
> 
> 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.

To maybe rephrase this in another way:

I think the distinction lies between “I want to narrow to this defun and work on it without distraction” vs “treat this region as an isolated buffer”. The former used by users, the latter used by lisp programs like Info and mmm-mode. The former still considers the visible region part of the whole buffer, just temporarily narrowed for convenience, the latter wants to make everything thinks the visible region _is_ the whole buffer.

 It might be good for tree-sitter or other parsers to be exempt from (but still acknowledges) the first kind of narrowing. This way the parser can avoid unnecessary re-parse, and always provide the optimal information. We just need to modify tree-sitter functions to check for this narrowing and don’t return anything beyond the boundaries. It’s probably going to be a lot of hair, but should be doable, I think?

This way, most lisp programs still obeys the narrowing, but specific things like tree-sitter can choose to secretly look around while still appear to obey the narrowing, when peeking around wouldn’t hurt. And when the narrowing is really indented, tree-sitter (or other parser) knows not to look around.


Yuan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.