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: Wed, 29 Jun 2022 20:43:50 +0300 Message-ID: <87tu83pbth.fsf@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25966"; 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 Wed Jun 29 21:16:48 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 1o6dBA-0006aV-18 for ged-emacs-devel@m.gmane-mx.org; Wed, 29 Jun 2022 21:16:48 +0200 Original-Received: from localhost ([::1]:48236 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o6dB8-0005Ul-M5 for ged-emacs-devel@m.gmane-mx.org; Wed, 29 Jun 2022 15:16:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49324) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o6cMq-0006aZ-Cr for emacs-devel@gnu.org; Wed, 29 Jun 2022 14:24:48 -0400 Original-Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]:43639) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o6cMo-0007TB-Hm; Wed, 29 Jun 2022 14:24:48 -0400 Original-Received: by mail-ed1-x533.google.com with SMTP id c13so23351901eds.10; Wed, 29 Jun 2022 11:24:45 -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=VtDtSKLcvpRDaDTVvdVij7tIAui/3oeq9uOIWwX59rA=; b=bj3kz6SP+psy2+J2TZqS5fEC+3illKAGSbgNHC6vDPYwqay6WO+k4vA/k6cJvyueOM SQQgOm9Rz2bR9Or5Q8hEA/NDa4GQgEdQmEuaaly3whk51PpfSF6VCh7yEAI0ijA73yUn p4hh98j4E1yUyyRdNmVbgl+jBTT6hF281lWq42fX0SDeKe7ODWH3ATu9XEkjjpwlhleU uNED7j5p/JBtVqFjirdPWHbd10IcDr0liH6Gj4AW6Sbpf6apU1KRFIHTdLYvvaX+esbo ZIEDbUbTrQOQfnLGswcjlTuyPFWjbFKK6bk6/1g4sjkCRM7ptNtyea6J6y+627FO9CbB Y/1Q== 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=VtDtSKLcvpRDaDTVvdVij7tIAui/3oeq9uOIWwX59rA=; b=l1C8MjjoRs/H+T9tbt47aghQe2BXZOjy5DV2Co9DCx9lCFdlqZMYga0j3Btv54eSAQ Sd38uKrJ6xHEwxsi+qC84OhSImfQTMEnQZJTdqrfnrufIPIXbKWmO624QfsEQIGPqGgA bihKyGJwjB8hjGdca4liZM2e8SAV/oexM7Ca6GvggNAiuykYKtTTTwk+yjf61SMgWgeW wyIHU4N1INrFDKnAs4onknIRL9JuQZrmZe2V2p3O+vAidDBN/n5kJU6M2+bg3VbxTKz9 +Rj9kR2xXJoVRjqHbgsfVciNk9Iy8RMWGq5DT2yfqXOcyVmVa6owH3k3RT7byphv1tnj ktoA== X-Gm-Message-State: AJIora+5YL5MLY6e77xOlaSI8bT72RWmJXsaz2PSxSMZeZ1uaDWLbt3w rZfm6wW5bk2HxiqWPwhMUvQ= X-Google-Smtp-Source: AGRyM1uGaF0jJ87gEOrb6ZTxoh0RJLmYzK8cthULpIZWH0LDg7r1YSMfpEprFcIX6CM4Hz1uoPSaDA== X-Received: by 2002:a05:6402:4410:b0:434:f35f:132e with SMTP id y16-20020a056402441000b00434f35f132emr6015052eda.215.1656527084477; Wed, 29 Jun 2022 11:24:44 -0700 (PDT) Original-Received: from localhost ([77.126.160.145]) by smtp.gmail.com with ESMTPSA id x6-20020aa7cd86000000b0043574d27ddasm11529892edv.16.2022.06.29.11.24.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jun 2022 11:24:44 -0700 (PDT) In-reply-to: Received-SPF: pass client-ip=2a00:1450:4864:20::533; envelope-from=yoavm448@gmail.com; helo=mail-ed1-x533.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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 29 Jun 2022 15:13:43 -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:291726 Archived-At: Cool that you're chipping in, we need feedback from the community and specifically package writers. Abin Simon writes: > Yoav Marco writes: > >> I could try to make a self-updating repo or something with CI - >> https://github.com/meain/evil-textobj-tree-sitter for example pulls >> highlights.scm changes from nvim's repo weeky. > > Just wanted to give a heads up that neovim has non standard items in > their queries. For example you will find things like `vim-match` and > `lua-match` in the queries. I guess we could support a "lisp-match" predicate, that would run a function and match if it returns non-nil. Or just try and look up non-existing predicates as Lisp functions. Would that be useful? > https://github.com/nvim-treesitter/nvim-treesitter/blob/989c75046c46d2ed96bb65c5badd6b8f785e7f09/queries/go/highlights.scm#L19 > > > 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. > > ref: https://github.com/meain/evil-textobj-tree-sitter/issues/33 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. Yuan, any thoughts on capture extensibility? Yoav