> On Nov 14, 2022, at 10:45 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Mon, 14 Nov 2022 10:29:56 -0800
>> Cc: monnier@iro.umontreal.ca,
>> theo@thornhill.no,
>> emacs-devel@gnu.org
>>
>>> Sorry, I don't understand: if the node's text did not change, and some
>>> other node (which did change) caused the first node to become
>>> "not-in-error", then why do we need to update the first node?
>>
>> Not specific to this node. I was saying that for any node to keep up with
>> changes made to the buffer text, they need to be updated with âinsertion in
>> X, deletion from X to Yâ. This is required by tree-sitterâs API. For this
>> particular node, not updating the node might be ok, depending on hoe
>> tree-sitter implements things. But of course we shouldnât rely on that.
>
> You mean, we must report the same "insertion in X, deletion from X to
> Y" change more than one time, because more than one node may depend on
> that change?
>
>>> And if
>>> the text of the node with the error did change, then we do update the
>>> node, don't we?
>>
>> Well we update the parse tree and re-parse, but we currently donât update
>> the nodes created from the old tree. Keeping all nodes updated requires us
>> to track all live nodes and update them whenever the buffer is edited.
>
> I guess I still don't understand what exactly do you mean by "update
> the node". Can you explain that in more detail?
My bad. So when buffer changes (insert in X, delete from X to Y), we inform
tree-sitter of this change by âupdatingâ the tree:
const TSInputEdit edit =
treesit_prepare_input_edit (start_byte, old_end_byte, new_end_byte);
ts_tree_edit (tree, &edit);
Then when we re-parse, tree-sitter knows which part of the buffer has changed
and needs to be re-parsed, and only parses those, hence âincremental parsingâ.
Tree-sitter nodes needs similar updates, so that it is in sync with the buffer
text.
>
>>> Please do. We must solve this problem.
>>>
>>> Btw, do other IDEs that use tree-sitter have the same problem? I
>>> doubt that, and if I'm right, we cannot afford having this problem in
>>> Emacs.
>>
>> I wouldnât call this a problem.
>
> It's a problem because highlighting in warning face is left on
> display, although the program source is correct and should have been
> highlighted differently.
I agree, I meant that not highlighting syntax errors isnât a problem per se.
>
>> Letâs not highlight syntax errors for now, and see how it looks. In the
>> meantime Iâll add the feature to track certain nodes for changes. Then if we
>> decide this is an important feature to have, we can look at how to implement
>> it.
>
> If you are working on this issue, we can leave things as they are in
> the meantime. Having the warning face show will provide motivation
> for solving this ;-)
>
>> I donât think Atom highlight parse errors, neovim disables it by default.
>
> We could decide to disable it by default, but let's first see how to
> solve the problem, or at least minimize it.
Yep.
Yuan
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4