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 18:16:02 +0300 Message-ID: <837diz866l.fsf@gnu.org> References: <837dj09p0e.fsf@gnu.org> <20210611232535.b4dyu3a2yxvdixys@Ergus> <87a6nw6jtf.fsf@telefonica.net> <20210612010844.45noqsg7wveeo3yw@Ergus> <83sg1n8t71.fsf@gnu.org> <20210612110103.u6kuh3d5vahxmxlt@Ergus> <83fsxn8gue.fsf@gnu.org> <20210612150402.5z2xpswor4dkxh7o@Ergus> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17990"; 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 17:17:02 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 1ls5Ne-0004Qh-P4 for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Jun 2021 17:17:02 +0200 Original-Received: from localhost ([::1]:45634 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ls5Nd-000393-4J for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Jun 2021 11:17:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55064) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ls5Mn-0001tg-DV for emacs-devel@gnu.org; Sat, 12 Jun 2021 11:16:10 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:42810) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ls5Mm-0005ny-SI; Sat, 12 Jun 2021 11:16:08 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2698 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 1ls5Mm-0005cy-DX; Sat, 12 Jun 2021 11:16:08 -0400 In-Reply-To: <20210612150402.5z2xpswor4dkxh7o@Ergus> (message from Ergus on Sat, 12 Jun 2021 17:04:02 +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:270768 Archived-At: > Date: Sat, 12 Jun 2021 17:04:02 +0200 > From: Ergus > Cc: ofv@wanadoo.es, emacs-devel@gnu.org > > >> 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. > > > They are not exclusive, but redundant. If we use the current > infrastructure then we will spend a lot of time translating properties > and contextual information. That depends on what you mean by "current infrastructure". > And avoiding to have part of them outdated. Navigation and > indentation will continue to be based on properties we need to set > and update all the time to make the match one by one. > > Basically we will be duplicating the information that is already in the > tree. Creating many list objects, overloading the gc, and so on. So we > potentially will save only the parsing time. Why would we do a silly thing like that? > The first one may work with a very primitive api to handle and iterate > the tree-sitter tree. The second one will require to use cursors, > finders and some other features from the tree-sitter API; improving > performance for sure but replacing a lot of the work lisp is doing now. > > The second approach will probably make happy the C developers more than > the Lisp ones. So where's the dilemma?