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: cc-mode fontification feels random Date: Sat, 12 Jun 2021 14:25:45 +0300 Message-ID: <83fsxn8gue.fsf@gnu.org> References: <83k0n09tkp.fsf@gnu.org> <837dj09p0e.fsf@gnu.org> <20210611232535.b4dyu3a2yxvdixys@Ergus> <87a6nw6jtf.fsf@telefonica.net> <20210612010844.45noqsg7wveeo3yw@Ergus> <83sg1n8t71.fsf@gnu.org> <20210612110103.u6kuh3d5vahxmxlt@Ergus> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2724"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ofv@wanadoo.es, emacs-devel@gnu.org To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 12 13:26:54 2021 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 1ls1mw-0000Uq-6V for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Jun 2021 13:26:54 +0200 Original-Received: from localhost ([::1]:47330 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ls1mu-0007DA-FY for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Jun 2021 07:26:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51374) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ls1m0-0006X0-GI for emacs-devel@gnu.org; Sat, 12 Jun 2021 07:25:56 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38400) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ls1lz-0003fI-EM; Sat, 12 Jun 2021 07:25:55 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4349 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 1ls1lz-0001s5-1y; Sat, 12 Jun 2021 07:25:55 -0400 In-Reply-To: <20210612110103.u6kuh3d5vahxmxlt@Ergus> (message from Ergus on Sat, 12 Jun 2021 13:01:03 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:270753 Archived-At: > Date: Sat, 12 Jun 2021 13:01:03 +0200 > From: Ergus > Cc: ofv@wanadoo.es, emacs-devel@gnu.org > > If I understand something about our cc-mode functionalities (and many of > those functionalities we don't want to loose like indentation and code > navigation). Probably the "right" way to use tree-sitter (maybe Alan > wants give a more precise technical description) is not only fontify but > use the tree information to add contextual information to the text > (something that I think cc-mode does.) And then let font-lock do the > magic. > > The tree-sitter tree is basically contextual information, and (for > example) if we have processed the whole buffer and we already have the > tree, then scrolling won't need to parse anything, adding or removing > text is a localized modification, so with the previous tree we can > re-parse only the modified region. The choice may be then if we > propertize the text of the whole buffer or just the visible region OR if > we want to "propertize on demand". > > This will save us from the hard parsing in cc-mode to fontify "on the > fly". I'm not sure I understand what you are suggesting. Can you describe your suggestion in terms of 'face' text properties and the 'fontified' property, and explain how those should fit into the existing redisplay mechanisms? > > I don't > >really care if TS actually processes a much larger chunk of text, if > >it does that quickly enough, but processing the resulting faces will > >take time on the Emacs side, and that is better avoided. > > But then we won't get all the contextual information we need for > indentation, code navigation or fold the code right? Why not? > I see two approaches here: > > 1) add the tree-sitter properties/faces to the buffer text (fully or > partially on the visible regions) > > 2) use the tree-sitter information directly from the tree and add the > visible properties from there. > > This second one will require a more complete api of tree-sitter > functions exposed to elisp, but in my opinion it worth it in accuracy, > speed and simplicity (a single API to rule them all). And to support > many languages we don't actually have like rust or the fancy C++ > 11. Why can't we have both? The information you are talking about, which is needed by Emacs features other than fontification, can be used by those other Emacs features when needed. You seem to be saying that these two alternatives are mutually-exclusive, but you didn't explain why.