|
From: | Gregory Heytings |
Subject: | bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes |
Date: | Thu, 30 Mar 2023 16:28:58 +0000 |
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) and (treesit-parser-set-included-ranges RANGES...) (the latter already exists).
Where "RANGES..." are included in [START..END], right?
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.
You mean, they will be independent, right? In other words, if the user sets the narrowing to 1000-1200 in a buffer in which treesit-make-parser has been called, say, once with 'php 400 1100' and once with 'js 1100 1500', the two parsers will continue to have access to these ranges?
Also, would such a parser always/never/sometimes obey the user narrowing?It will always obey narrowing (it must), but we can then widen the buffer temporarily inside some functions without caring about the semantics of the narrowing and its source/purpose.
Here I'm confused, that sentence seems to contradict the previous one. "It" in "it will always obey narrowing" is the parser, right, and "narrowing" is "the narrowing bounds set by 'treesit-make-parser'", right?
[Prev in Thread] | Current Thread | [Next in Thread] |