> 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4