From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Tree sitter support for C-like languages Date: Mon, 14 Nov 2022 14:55:02 +0200 Message-ID: <83mt8tk861.fsf@gnu.org> References: <87tu36em9t.fsf@thornhill.no> <45FD2F78-F15B-488B-9348-A8E298D8AD35@gmail.com> <87v8nmyqqp.fsf@thornhill.no> <834jv4nz2g.fsf@gnu.org> <871qq8hsj1.fsf@thornhill.no> <83iljklzmo.fsf@gnu.org> <87v8nkgcqj.fsf@thornhill.no> <87sfiogcbm.fsf@thornhill.no> <83pmdrkyj7.fsf@gnu.org> <87v8njw5th.fsf@thornhill.no> <83leofkwjm.fsf@gnu.org> <9E9244D3-2EFB-4621-91E0-FC8B8C1C2D52@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28444"; mail-complaints-to="usenet@ciao.gmane.io" Cc: theo@thornhill.no, emacs-devel@gnu.org, monnier@iro.umontreal.ca To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 15 00:59:17 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oujMB-00079h-Dv for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Nov 2022 00:59:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ouinC-0007Hb-MT; Mon, 14 Nov 2022 18:23:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ouifT-0002E1-JD for emacs-devel@gnu.org; Mon, 14 Nov 2022 18:15:09 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ouYzS-0008Gk-9Q; Mon, 14 Nov 2022 07:55:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=fujGGAWbVjT8xeNRjYKj7RdbfuC15GDa9eUIzlGNVpk=; b=ghcjVLiV2X4AjNVh3AYK ajIl0/7JCjH62i+k33QT5CquM8tn4waw4JeiBh0khrNDbb+3BC3bcwHoJ5GxL+JPrYwus1qul7XOk v+bNyhxQ39LEZ5rYXlnzE69i3gStcch2sFK7co1hp6I4xnDSdqBAj/EpLgaO8+imKeuN+mQXqqc6H iP3nGOKeLuNrW4GZq3WX+V9aSo7PUFC76zVB6TrCMj+j6iFzDoOeEZU+/EyuwUoIVgoAK1LnM7GqU FOd2OV8wHUXOeQT+Qhmcz64XBfdovudgiipco7c7vMqEkWYbKy+QEq1tDPDhRJGzIG8TREnEoBPNk EzZyObM7RcmI+A==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ouYzC-0004DV-Fx; Mon, 14 Nov 2022 07:54:57 -0500 In-Reply-To: <9E9244D3-2EFB-4621-91E0-FC8B8C1C2D52@gmail.com> (message from Yuan Fu on Sun, 13 Nov 2022 16:22:36 -0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:299784 Archived-At: > From: Yuan Fu > Date: Sun, 13 Nov 2022 16:22:36 -0800 > Cc: Theodor Thornhill , > emacs-devel , > 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.