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:35:57 +0300 Message-ID: <834ke3859e.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> <837diz866l.fsf@gnu.org> <20210612152344.4tyayrlk6ur7ujmt@Ergus> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29621"; 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:36:59 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 1ls5gw-0007Yy-T3 for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Jun 2021 17:36:58 +0200 Original-Received: from localhost ([::1]:54156 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ls5gv-0001aj-UZ for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Jun 2021 11:36:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56946) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ls5g4-0000vk-OX for emacs-devel@gnu.org; Sat, 12 Jun 2021 11:36:04 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43084) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ls5g3-0001Jd-Qh; Sat, 12 Jun 2021 11:36:03 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3920 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 1ls5g3-0002lm-Ca; Sat, 12 Jun 2021 11:36:03 -0400 In-Reply-To: <20210612152344.4tyayrlk6ur7ujmt@Ergus> (message from Ergus on Sat, 12 Jun 2021 17:23:44 +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:270770 Archived-At: > Date: Sat, 12 Jun 2021 17:23:44 +0200 > From: Ergus > Cc: ofv@wanadoo.es, emacs-devel@gnu.org > > >> 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". > > > Properties, properties navigation. If you mean the special properties used by CC Mode, then we are not restricted by using them. We can invent new ones, if needed. Or use something other than text properties, if that makes sense. IOW, I don't see why this would be something we need to bother about at this point. > >> 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? > > > to convert the tree into some lisp objects we can use with lisp > functions (to check, read, compare and so on) > > >> 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? > > > For me none, but lisp developers may not like to rely so much in an > external library. We could have accessor functions exposed to Lisp, if that's needed. Again, I don't see why this should bother us now. We have enough means to solve these problems.