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: Tue, 21 Jun 2022 05:26:53 +0300 Message-ID: <83letqlpjm.fsf@gnu.org> References: <2c2746e5f2558a87e8eab6f0914264a020173a9d.camel@pm.me> <27630AA3-8026-4E24-8852-ACCD9325B99D@gmail.com> <0E9E702B-B07C-4794-8498-29B9320E14CC@gmail.com> <83letvq0ii.fsf@gnu.org> <6EA831D3-A9C9-4346-B1E8-7748BAB285E2@gmail.com> <83czf7pocp.fsf@gnu.org> <83tu8io5i5.fsf@gnu.org> <83edzmnymo.fsf@gnu.org> <211D7584-1B0C-4A37-8ADF-08E1942BA719@gmail.com> <83zgi9mcu4.fsf@gnu.org> <70DEA4FC-2F93-4890-9F13-6C00D7278065@gmail.com> <83bkunmuds.fsf@gnu.org> <4E08A965-8C79-4544-8A0F-2CC2BDEBF194@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40363"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jun 21 04:27:42 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 1o3TcE-000AJV-5i for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Jun 2022 04:27:42 +0200 Original-Received: from localhost ([::1]:40904 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o3TcD-000251-2p for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Jun 2022 22:27:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50728) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3Tbe-0001Lp-Iv for emacs-devel@gnu.org; Mon, 20 Jun 2022 22:27:06 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35642) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3Tbe-0001mw-BK; Mon, 20 Jun 2022 22:27:06 -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=u2jEI6mmaA/eeHqvTSwWTCkkOH8aHcahQrGEKhaZ8ng=; b=JNr3aVegw4wE Lc2MGAH9kyIbzCa3+Atbfaz3PDYmGg5As3q3aTZGegXM/M4Tqe7NqklkGQxhj61q05VtpMN4SP9tc o7y2QTcJT5dGUcVAf/NjPftRa3NjYujkkt6S+XfGtiFYWi4XWevU8cGFnIPJ5q33Lzth6NFgI2iDi JKO8UN6cBJCgxxEg4NgjxeH7DZKuKq5Wd8hzA6X69GvXYrlM5Of6YDvH1oyqskfGb+JSfF12YSv+m Z0mSswhaUT9Nh3lge1js2DcQEECHYFY9z7ZCtb/fWs/Ie6HMXv2KCeyjQuynWlMDv0I8MGBFxNYAL mIesQSQELflxbx4Q0mNgzQ==; Original-Received: from [87.69.77.57] (port=4353 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 1o3Tbd-0002Qs-RS; Mon, 20 Jun 2022 22:27:06 -0400 In-Reply-To: <4E08A965-8C79-4544-8A0F-2CC2BDEBF194@gmail.com> (message from Yuan Fu on Mon, 20 Jun 2022 13:01:32 -0700) 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:291477 Archived-At: > From: Yuan Fu > Date: Mon, 20 Jun 2022 13:01:32 -0700 > Cc: emacs-devel@gnu.org > > Major mode should set beginning-of-defun-function to treesit-beginning-of-defun, not unlike what they already do with major mode-specific beginning-of-defun functions. This way major mode has the freedom to decide which treesit features it wants to leverage. Then those tree-sitter functions should be described together with beginning/end-of-defun, I think. > >> Treesit-beginning/end-of-defun jumps to the beginning/end of the current defun form, treesit-search-beginning searches for a query and stops at the beginning/end of the node that matched the query. > > > > So you are saying treesit-beginning/end-of-defun don't actually look > > for beginning and end of a function, but for beginning and end of a > > more abstract entity? Then perhaps it would be wrong to have "defun" > > in their names? And in that case, maybe a separate section (under > > "Motion") is better after all, since this is no longer "List Motion", > > strictly speaking. > > The second sentence describes treesit-search-beginning, not treesit-beginning-of-defun, I think you confused the two? Maybe so, but why did you mention treesit-search-beginning in this context to begin with?