Re: Initial fontification in sh-mode with tree-sittter

[Yuan Fu]

> On Nov 3, 2022, at 9:08 AM, João Paulo Labegalini de Carvalho 
> <jaopaulolc@gmail.com> wrote:
> 
> Thanks for working on this.
> 
>> The deeper problem is, if there is some regex-based-font-lock face in region 
>> A (applied when Emacs fontified region A), eg, highlighted TODO keywords in 
>> a docstring, they will be overwritten by the string face, if we just apply 
>> string face to the whole string and trigger redisplay.
> 
> I still need to get familiar with the parts of the code involved. But can we 
> avoid this (potentially) expensive re-fontification by keeping a list of text 
> properties/fonts applied to a region? Because if the region was not changed, 
> aside from adding/removing comments, then it would not need to be re-parsed.

This shouldn’t be expensive, and most work is delayed until the region is 
actually displayed. I wouldn’t worry about it. 

>  
>> What I ended up doing is to set jit-lock-context-unfontify-pos to the 
>> beginning of the string node (aka beginning of region A). Then in a timer 
>> jit-lock-context will refontify everything after that position. And I have 
>> some measure to break possible infinite recursion (fontify region -> set 
>> jit-lock-context-unfontify-pos -> cause refontification -> fontify region -> 
>> …).
> 
> I still need to look at your fix more carefully as a similar issue exists for 
> sh-mode and heredoc strings.

All you need to do is capture these contextual nodes in a special name 
“contextual”.

(heredoc_body) @contextual
(string) @contextual

This should take care of updating faces. But I don’t know about the bleeding 
you described in the very beginning. Do you still see it? Is there a recipe to 
reproduce it?

Yuan