[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain ch
From: |
Yuan Fu |
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@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
- bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes, (continued)
- bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes, Eli Zaretskii, 2023/03/29
- bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes, Dmitry Gutov, 2023/03/30
- bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes, Dmitry Gutov, 2023/03/30
- bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes, Eli Zaretskii, 2023/03/31
- bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes, Eli Zaretskii, 2023/03/31
- bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes, Dmitry Gutov, 2023/03/31
- bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes, Eli Zaretskii, 2023/03/31
- bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes, Dmitry Gutov, 2023/03/31
- bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes, Dmitry Gutov, 2023/03/31
- bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes, Eli Zaretskii, 2023/03/31
- bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes,
Yuan Fu <=
- bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes, Dmitry Gutov, 2023/03/31
- bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes, Dmitry Gutov, 2023/03/27
- bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes, Eli Zaretskii, 2023/03/27
- bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes, Dmitry Gutov, 2023/03/27
- bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes, Eli Zaretskii, 2023/03/28
- bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes, Dmitry Gutov, 2023/03/28
- bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes, Eli Zaretskii, 2023/03/29
- bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes, Gregory Heytings, 2023/03/30
- bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes, Eli Zaretskii, 2023/03/30
- bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes, Gregory Heytings, 2023/03/30