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: conceptional problem solvable at Emacs' level? Date: Sat, 11 Feb 2023 12:42:10 +0200 Message-ID: <83cz6gjxfh.fsf@gnu.org> References: <87zg9n45ig.fsf@yahoo.com> <0DDF6978-D75A-4137-9D93-6200908675B6@gmail.com> <837cwplxni.fsf@gnu.org> <87bkm0czpp.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11435"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, luangruo@yahoo.com, holgerschurig@gmail.com, Emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Feb 11 11:43:29 2023 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 1pQnLt-0002mg-36 for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Feb 2023 11:43:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pQnL8-0006u8-4j; Sat, 11 Feb 2023 05:42:42 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pQnL6-0006tt-Ge for Emacs-devel@gnu.org; Sat, 11 Feb 2023 05:42:40 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pQnL6-0006wu-6J; Sat, 11 Feb 2023 05:42:40 -0500 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=waa1jZd+bdomaMtueAOMIwa7NByARNuJXVlMQKEtcbA=; b=EUopThGJp4RA 8ZOIchlRehSnTUGCo4vVeX1nxcoq+KtSCcv8wVbSf6Eas51MJPukeLrZEv9k2QS07FPx+/5McCRsB qSZkrY5RhMfp1ghM87u1h8dtQLrQ5I1d+R28m+FSP3jKr8GC+ASkgyOo+zJnLq3o46KCa+yt/AO9T C4nWNLmiSN05U2lxGEfPNWY839AsE9ctDj78nOc3N+RrG61xs9MReqPhfkhUuxztHHMX55KojaYJK TgQoivLCgGFT0YVSRD+f86uvR4gG49yvmYALLtqiJ57tnmnCGRkVYuZ75D0ZDCTORmvbPcUDEN3bc xBU5CXr10QnBFjQpOvW0Ng==; Original-Received: from [87.69.77.57] (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 1pQnL5-0006Y4-Fg; Sat, 11 Feb 2023 05:42:39 -0500 In-Reply-To: <87bkm0czpp.fsf@localhost> (message from Ihor Radchenko on Sat, 11 Feb 2023 09:34:42 +0000) 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:303136 Archived-At: > From: Ihor Radchenko > Cc: Yuan Fu , luangruo@yahoo.com, > holgerschurig@gmail.com, Emacs-devel@gnu.org > Date: Sat, 11 Feb 2023 09:34:42 +0000 > > Eli Zaretskii writes: > > > Another possibility is to complicate the function we pass to > > tree-sitter with which to read buffer text, in a way that replaces the > > text of a macro with something else (in the simplest case, just space > > characters), so as to avoid errors in the parser, and again analyze > > the macros in our own code. > > Another idea is delegating parts of buffer to Elisp/alternative parser. Could be. However: > Tree sitter provides support to documents written using a mixture of > grammars: https://tree-sitter.github.io/tree-sitter/using-parsers#multi-language-documents > Macros can be considered such a "mixed" grammar with macros being a > grammar of their own. > > AFAIU, tree sitter allows excluding certain file ranges from parsing > and instead parse the excluded ranges using alternative grammar. If > Elisp can somehow tell tree-sitter backend not skip parsing > macro-looking lines, it should solve the problem at least partially. I believe the problem is with handling the parts which _use_ the macro, not those parts which _define_ macros. Still, this idea should be explored, I think. Thanks.