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 integration on feature/tree-sitter Date: Fri, 13 May 2022 13:37:05 +0300 Message-ID: <835ym9oh0u.fsf@gnu.org> References: <87y1zabmbt.fsf@gmail.com> <5F186EBD-CD21-422B-8B4F-0D5424173334@gmail.com> <875ymdwf76.fsf@gmail.com> <011DA1A3-0FA8-4449-878A-FD6B336B0F1B@gmail.com> <8735hhw75p.fsf@gmail.com> <83czgks4ss.fsf@gnu.org> <87wnesuw63.fsf@gmail.com> <83pmkkqhft.fsf@gnu.org> <87tu9wukbt.fsf@gmail.com> <83ee10qbk7.fsf@gnu.org> <8F6A43D1-D1EA-4602-A245-627DB7960FC2@gmail.com> <838rr7qqhw.fsf@gnu.org> <87sfpekf6t.fsf@gmail.com> <838rr6pwjt.fsf@gnu.org> <87pmkik7x6.fsf@gmail.com> <83wneqoej5.fsf@gnu.org> <87mtfmk4oi.fsf@gmail.com> <83ee0yndor.fsf@gnu.org> <87r14xq2oc.fsf@thornhill.no> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27057"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yoavm448@gmail.com, casouri@gmail.com, emacs-devel@gnu.org To: Theodor Thornhill Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 13 12:38:51 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 1npSh8-0006sT-B8 for ged-emacs-devel@m.gmane-mx.org; Fri, 13 May 2022 12:38:50 +0200 Original-Received: from localhost ([::1]:51158 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1npSh7-0003iN-AK for ged-emacs-devel@m.gmane-mx.org; Fri, 13 May 2022 06:38:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:32850) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1npSfM-0001gj-UK for emacs-devel@gnu.org; Fri, 13 May 2022 06:37:00 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41130) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1npSfM-0004k9-5g; Fri, 13 May 2022 06:37:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=HenxXhN/HYXL4AVCMe2ALqSwOjt42YjDCC8UXEToJTI=; b=L82cxdXsy5Xe E1/3yG760Kj0AFlefAG7ZAmjQ2YrAhzgnMncH3x33eaPUCf6nSOB1zKYd7l5QdMir7Lqp+xSJ6IGT fqiroF8QlFAG7BP+m1Xck//o7VKyDJL6rE8SlB1YVXczjPWDd6UHHZmHfnpWY/Uuz+ii5WBQx/80w U/ay+agi/6cKi6/wI+mNw5MgaZMkr4Tn6YAg8MlanxGWWMr8iy2qt8OYyYj5oJ8PVA+Leu5IJYX2i sajSY+zFMk7lJQ/84mfrG0D1JYL2TXWF4jZQPKenQCZS+Z2SjcPRMdCg3cKveqTK4at3ZltxNbPbc vf+QqVAi/nAgPYaUXXp0Mw==; Original-Received: from [87.69.77.57] (port=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 1npSfL-0007xa-Ev; Fri, 13 May 2022 06:36:59 -0400 In-Reply-To: <87r14xq2oc.fsf@thornhill.no> (message from Theodor Thornhill on Fri, 13 May 2022 10:04:03 +0200) 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" Xref: news.gmane.io gmane.emacs.devel:289720 Archived-At: > From: Theodor Thornhill > Cc: casouri@gmail.com, emacs-devel@gnu.org > Date: Fri, 13 May 2022 10:04:03 +0200 > > > Is it true that there's just one query for each PL mode, and it is > > fixed (doesn't change) and doesn't depend on the buffer contents in > > any way? If that is true, the major mode could compile the query > > whenever it is initialized, and then reuse it in every buffer that is > > under that major mode. > > > > Yes, for indentation and font locking, this is correct. I'd think that > it'll be enough to compile on mode init, and just reuse it. For some > hypothetical other uses, such as searching and replacing, we would need > to be more dynamic, but that won't have the performance issues that font > locking typically has. Right. > Why not use the same idea as the `eglot-managed-mode`, where if the > file fulfills some predicate, we choose to treat them all as equals. > Thus we only need to compile/read/use the queries once, and can > simply lookup what we need. We can do something like that if needed. But I don't necessarily see the need yet. When will we need this, if a major mode compiles the query once when it is first turned on in some buffer? > > There isn't any (IIUC what you are asking). Fontification is a > > feature of interactive sessions, and is basically meaningless without > > normal redisplay. > > > > An ok benchmark would be using C-n rather than C-v, because that seems > to trigger more performance issues in my daily use. We should benchmark both, because both are important.