You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SwiftTreeSitter provides a includedRanges array binding to the tree-sitter parser that would allow us to set what ranges tree-sitter acts on. Right now, tree-sitter parses the entire document when initialized. This isn't a huge problem, as it's very fast and by a quick tests parses very large files in only a few milliseconds. However, this is still a large inefficiency and something that should be implemented.
What would need to be done:
Add a way for Highlighter to provide HighlightProviding objects with the "effective range", basically the visibleSet we already calculate.
Modify TreeSitterClient to use the effective range and to update the ranges in real time.
Closing this because the includedRanges parameter doesn't apply to this problem well. If we were to use it to try and make editing faster, the syntax tree tree-sitter creates will be incomplete and buggy. It will also not shrink if the includedRanges shrink, so the editing time improvement will be nonexistent for larger files where it matters.
Instead, we should look into backgrounding long edit times using the timeout parameter on parsers. Swift's async/await would be perfect here.
Activity
thecoolwinter commentedon Mar 16, 2023
Closing this because the
includedRangesparameter doesn't apply to this problem well. If we were to use it to try and make editing faster, the syntax treetree-sittercreates will be incomplete and buggy. It will also not shrink if theincludedRangesshrink, so the editing time improvement will be nonexistent for larger files where it matters.Instead, we should look into backgrounding long edit times using the
timeoutparameter on parsers. Swift's async/await would be perfect here.