|
From: | Dmitry Gutov |
Subject: | Re: Tree sitter support for C-like languages |
Date: | Mon, 14 Nov 2022 21:54:01 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 |
On 14.11.2022 10:35, Yuan Fu wrote:
On Nov 13, 2022, at 5:26 PM, Dmitry Gutov <dgutov@yandex.ru> wrote: On 14.11.2022 02:22, Yuan Fu wrote:So if we want the warning face to automatically disappear, we need to record these warning faces and remember to come back to refontify them later. We need to know when to refontify them, and know when to stop trying to refontify them (maybe the error isn’t transient). For now I think it’s best to just not fontify the error nodes.I'm guessing the situation could be the reverse as well: after the user typing some chars, the warning would need to be *added* rather than removed, in some cases.That’s a good perspective. But from what I see I think it’s best not to fontify these “errors”, at least for C and C++. Because a lot of things could be marked “error” in a C file, like stuff around macros. And in extreme cases the whole file is marked “error”, even though if we ignore the error everything is parsed fine. I guess tree-sitter isn’t happy about some tiny thing in that file but never the less can parse everything correctly. I attached that file below.
Perhaps not in C/C++, but other langs could use them.Also (and here I'm really guessing, not sure what the limitations/benefits of TS grammars are) there might be other nodes which could change due to the user writing or deleting code on subsequent lines.
Any chance tree-sitter gives you some info/callbacks to convey the earliest node (closes to bob) which has changed after the most recent buffer modification? So we'd refontify starting with its beginning position.Yes and no, I explained in more detail in another message.
If you're referring to this grandparent message: > jit-lock doesn’t know it needs to be refontified...then I suppose it's a matter of letting it know somehow. I haven't read the TS integration code yet, so I'm not sure at which level it integrates with jit-lock.
But jit-lock-functions are allowed to fontify more than the passed in boundaries, for example.
[Prev in Thread] | Current Thread | [Next in Thread] |