emacs-devel
[Top][All Lists]
Advanced

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

Re: Tree sitter support for C-like languages


From: Eli Zaretskii
Subject: Re: Tree sitter support for C-like languages
Date: Mon, 14 Nov 2022 14:55:02 +0200

> From: Yuan Fu <casouri@gmail.com>
> Date: Sun, 13 Nov 2022 16:22:36 -0800
> Cc: Theodor Thornhill <theo@thornhill.no>,
>  emacs-devel <emacs-devel@gnu.org>,
>  monnier@iro.umontreal.ca
> 
> That’s just due to jit-lock. When jit-lock first fontifies
> 
> int
> foo (void)
> {
> 
> The parse tree has errors and it fontifies int in warning face.
> 
> Then when you insert the closing bracket, the parse tree is complete
> 
> int
> foo (void)
> {
>  int bar = 0;
> }
> 
> Int is still in warning face because jit-lock doesn’t know it needs to be 
> refontified. When you insert a newline in BOB, jit-lock refortifies 
> everything after the changed region, so int is refontified. 
> 
> 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 don't think this will fly with the users.  Leaving valid code marked
with the warning face is a misfeature, and the fact that it disappears
after a random change before the offending text makes that apparent to
everyone.  We should fix this one way or the other, or we will get
many justified bug reports.

Please research the possible ways of knowing which nodes that were in
error are no longer in error (or vice versa), and let's discuss how
best to solve this problem.  We cannot release Emacs 29 with modes
which exhibit this problematic behavior.

Thanks.



reply via email to

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