From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yoav Marco Newsgroups: gmane.emacs.devel Subject: Re: Tree-sitter integration on feature/tree-sitter Date: Thu, 30 Jun 2022 14:21:54 +0300 Message-ID: <87y1xeb93m.fsf@gmail.com> References: <87tu83pbth.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23142"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.6.3; emacs 29.0.50 Cc: casouri@gmail.com, eliz@gnu.org, theo@thornhill.no, monnier@iro.umontreal.ca, dancol@dancol.org, emacs-devel@gnu.org To: Abin Simon Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jun 30 15:59:11 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 1o6uhK-0005rE-HE for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Jun 2022 15:59:10 +0200 Original-Received: from localhost ([::1]:55920 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o6uhJ-0005tF-9w for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Jun 2022 09:59:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33468) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o6tlq-0004TU-1E for emacs-devel@gnu.org; Thu, 30 Jun 2022 08:59:46 -0400 Original-Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]:44876) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o6tlZ-0005g0-Oe; Thu, 30 Jun 2022 08:59:44 -0400 Original-Received: by mail-wr1-x42b.google.com with SMTP id i1so22694424wrb.11; Thu, 30 Jun 2022 05:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version; bh=2Cfgnm+rhMjxP0+dbfNnv6sXKAEkiT/KtyuouUn9gng=; b=MBN+EX8ch29iIrzmQvk3gPnOJmmZsohrMVzKVnwb6r5+02fa6JQ2R+LwcSXsPGo4Iv 9CbJHCQCdtfP9mcgFgmRdFLo3oMoEX8L4ZW4pEE9/LP8anMx9dj7O0vH50RfFFmYZPVv byDixNVN8dNC4BtZjkXw2kIo37P8WVfW7GCzl59XvX9zqE3BgFlg+VhnnFEupRSFimn5 PPK24+JMEZAS8DJRpNOn6Yzt562iVMfRyOsiRxm1mMhjsY/3p8tedZIMDV0ByH8sPPbr 7JuiOajZGPg2Ifuo9gb4ReL+Ftxupd9kBLvLlPK2xoTlSr8Wf7EWbX8/ESSA6bW2SenR VtEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version; bh=2Cfgnm+rhMjxP0+dbfNnv6sXKAEkiT/KtyuouUn9gng=; b=qyEj6gAcZHlA52VV1gQum6e8Jh3Bdxv3e1btCNCEK0mdAtn97NQEK1QSpCp7dj7HAw V3EQ/C1LTrJTbmZ18W6FKKMUP1K+pHVASRclHQD2G7ija/knvN22lXkxMybxIVsfRcH9 xZXHUSgx8S6MFrqBLEgSU8NT/wLrD4QVS31CqJ9WmzHu/8qweDJLzUpdD54pLSAP+W86 J0zg8YeISVeP9OCsgCvG+Bawy3zR3NGGuGvj3GgdnOgMpJEM2LrV4Q5DTZNlrygX2IYw c41W4GNofv+6oEgFCvGkLm1ytNjBWjq+srdHjXIK9IQ5ZpgCxEPfNyOaxESfpAC2APua rEUA== X-Gm-Message-State: AJIora+Ep3Hi2Opf1whbJYvtbuGJ/uFy4U3j3e3/MkTaNpE07vTMa9kV ZSzadrMWpWyVcOcW5vwGAFjw8cXzAv62kg== X-Google-Smtp-Source: AGRyM1v5xqRHjRbz272H1/LOgoi9sOPAI9a3xIxh9B/SP+O+vF/j8kSVatDQ877XX5MaJeu4zlcxNA== X-Received: by 2002:a5d:48cf:0:b0:210:1229:2e7 with SMTP id p15-20020a5d48cf000000b00210122902e7mr8257003wrs.567.1656593966792; Thu, 30 Jun 2022 05:59:26 -0700 (PDT) Original-Received: from localhost ([2a0d:6fc0:2817:d700:159d:ab98:95d7:9918]) by smtp.gmail.com with ESMTPSA id l34-20020a05600c1d2200b003a03e63e428sm3360107wms.36.2022.06.30.05.59.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Jun 2022 05:59:26 -0700 (PDT) In-reply-to: <87tu83pbth.fsf@gmail.com> Received-SPF: pass client-ip=2a00:1450:4864:20::42b; envelope-from=yoavm448@gmail.com; helo=mail-wr1-x42b.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 30 Jun 2022 09:57:48 -0400 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:291743 Archived-At: Yoav Marco writes: > Okay, so the problem here is that neovim supports making up arbitrary > captures as a range over other captures: (#make-range! "c" @a @b) means > "make a new capture @c that spans from @a to @b". It helps when you e.g > want to make a capture spanning only two children of a node and not the > other children. > > The problem is, making up new captures in Lisp isn't trivial, it would > need special support form the C side. > > Could we support this? > > 1. We could allow a special case where if Lisp predicate return a list > (name beg end) that would have the same effect as "make new capture > @c with range @a, @b". > > 2. But captures are returned from treesit-query-capture as pairs of > (capture-name . node), and we can't just make up a node with > arbitrary range. > > 3. We could report non-boolean capture results by just appending that > result to the list of pairs, but that just adds complexity to users > of treesit-query-capture. And it doesn't support the simpler use case > of 1, where it's just reported as a normal capture. I dug a little through the neovim code. #make-range! is implemented in nvim-treesitter, not mainline neovim. And they don't create a new node for the range, just compute the range itself. I think the best course of action is to support elisp predicates in some way, and let users post-process the output of treesit-query-capture if they added queries that return non-boolean results. > Abin Simon writes: > >> I ran into similar issues in the meain/evil-textobj-tree-sitter and had >> to write scritps to convert them to something that works in emacs. I see you wrote a go program to pre-process #make-range!. I also had to do something similar in https://github.com/emacs-tree-sitter/tree-sitter-langs/pull/99 due to predicate incompatibility, though I do it in Elisp right after reading the query file. So I guess it's a valid solution too.