|
From: | Dmitry Gutov |
Subject: | bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes |
Date: | Fri, 31 Mar 2023 04:25:41 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 |
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.orgNo, 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).
[Prev in Thread] | Current Thread | [Next in Thread] |