[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: |
Eli Zaretskii |
Subject: |
bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes |
Date: |
Fri, 31 Mar 2023 09:22:55 +0300 |
> Date: Fri, 31 Mar 2023 04:25:41 +0300
> Cc: wkirschbaum@gmail.com, casouri@gmail.com, 62333@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
>
> On 30/03/2023 19:04, Eli Zaretskii wrote:
> >> Date: Thu, 30 Mar 2023 15:50:31 +0000
> >> From: Gregory Heytings <gregory@heytings.org>
> >> cc: Dmitry Gutov <dgutov@yandex.ru>, wkirschbaum@gmail.com,
> >> casouri@gmail.com,
> >> 62333@debbugs.gnu.org
> >>
> >>> No, the idea is to create the parser with these restrictions to begin
> >>> with.
> >>
> >> Could you perhaps explain, with some fictitious code, what kind of
> >> solution you imagine? I'm not sure I understand (euphemism for: I'm sure
> >> I don't understand) the problem statement.
> >
> > Something like
> >
> > (treesit-make-parser LANGUAGE BUFFER nil START END)
>
> What kind of code would be calling this?
>
> What happens when the user types a character before START? What happens
> when they delete a character at START or END? Or a whole line?
>
> > and
> >
> > (treesit-parser-set-included-ranges RANGES...)
> >
> > (the latter already exists).
>
> Indeed, a way to do this using tree-sitter indeed already exists,
> offloading the parsing of the regions to tree-sitter. OTOH, this way we
> only get tree-sitter features sorted into regions (parse tree,
> indentation, highlighting).
>
> Whatever other Lisp-level features we wanted to behave differently
> between regions, we'd have do implement them the old way.
>
> >> In what way would the restrictions you have in mind be different from
> >> those of a regular narrowing?
> >
> > User-defined narrowing will never contradict parser restrictions.
>
> IOW, user-defined narrowing should be only for visual purposes, as
> described in another email. And perhaps to restrict movement (which is
> related: you can't move to where you can't see).
I'm sorry, I cannot afford a discussion where you decided up front you
disagree, and just keep looking for arguments in favor of your
disagreement. Such discussions are a waste of our time, and I have
very little of it to waste. So I won't be responding to any further
messages here, unless they ask informative questions where I think I
can contribute something useful.
- 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, 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
- 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
- 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
- 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/31
- 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 <=
- bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes, Dmitry Gutov, 2023/03/30