Re: Tree sitter support for C-like languages

[Yuan Fu]

> On Nov 14, 2022, at 11:54 AM, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> 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.

Yes, this is common for comments and multi-line strings. And we can correctly 
handle them now, yay (see my other message.)

> 
>>> 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.

It plugs into font-lock, but it also secretly knows about jit-lock… We now can 
tell what parts of the buffer are affected/changed, and we set fontified to nil 
in those areas so redisplay will refontify them.

> 
> But jit-lock-functions are allowed to fontify more than the passed in 
> boundaries, for example.


Yuan