[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tree sitter support for C-like languages

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 

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]