From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Wilhelm Kirschbaum Newsgroups: gmane.emacs.bugs Subject: bug#58711: Treesit hangs when calling treesit-search-forward Date: Thu, 10 Nov 2022 08:44:50 +0200 Message-ID: References: <895A3C87-507A-4FC5-8BAE-B138B35CD40C@gmail.com> <46B629C0-1413-41CE-BDA8-CE14C12B4449@gmail.com> <3054006.Zh9iicr411@melissa.local> <106B8822-FE37-4590-BC77-5FB24FB0758C@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000c9d11905ed181ce4" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15645"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 58711@debbugs.gnu.org To: Yuan Fu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 10 07:46:28 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1ot1KW-0003qZ-1W for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Nov 2022 07:46:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ot1K9-0008Ha-CH; Thu, 10 Nov 2022 01:46:05 -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 1ot1K6-0008HI-Uo for bug-gnu-emacs@gnu.org; Thu, 10 Nov 2022 01:46:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ot1K6-0000ly-DF for bug-gnu-emacs@gnu.org; Thu, 10 Nov 2022 01:46:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ot1K6-0000A6-8l for bug-gnu-emacs@gnu.org; Thu, 10 Nov 2022 01:46:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Wilhelm Kirschbaum Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Nov 2022 06:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58711 X-GNU-PR-Package: emacs Original-Received: via spool by 58711-submit@debbugs.gnu.org id=B58711.1668062710542 (code B ref 58711); Thu, 10 Nov 2022 06:46:02 +0000 Original-Received: (at 58711) by debbugs.gnu.org; 10 Nov 2022 06:45:10 +0000 Original-Received: from localhost ([127.0.0.1]:41668 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ot1JG-00008g-AW for submit@debbugs.gnu.org; Thu, 10 Nov 2022 01:45:10 -0500 Original-Received: from mail-lf1-f49.google.com ([209.85.167.49]:45847) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ot1JD-00008A-UO for 58711@debbugs.gnu.org; Thu, 10 Nov 2022 01:45:09 -0500 Original-Received: by mail-lf1-f49.google.com with SMTP id j16so1357713lfe.12 for <58711@debbugs.gnu.org>; Wed, 09 Nov 2022 22:45:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=floatpays.co.za; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9eJBByvkwX4UIVdqDY4BBaoV8kCXjB7j7hv58tVh7RA=; b=TmI2s35ycVnUV2Fiix3Z4Xl47aa2L7EyWCidsoh/GHfPx+3MSy5MxnXXIBkH5LYu/J an5v7noXUVgbsNdQ0e+jTorSEdjBq3ZlfHS1Ev1A2WTYOSkr7IXIhXOElNKOJpv/0odR rIMTl1PL9XHcjx5kO9j614OlA38JJXxfvYIz0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9eJBByvkwX4UIVdqDY4BBaoV8kCXjB7j7hv58tVh7RA=; b=SEja1XXwQ84FIDN6R5DUSRrKlwJqfzbPvcr854kld7Sp4uIDobR2QxaASPplfq3V+n 1bYv7wUV0JW8IwWeImfSyvBf1daWMefkcKYP7BSjpx1nJnLLOvgePDZaK82tK2SYMozN JUXK5GoVSHIRrsG1ewM4YHCMJL7XAxBDQluiJtf55dcGhLBnFjLM8hxGJEdItRRVLRQM e+KYq545c8F12pXRHO3rjVDV+1R2ltO9WNijvSFEkz8yMt4+1j6TA/8+M+DFB2Bg4xVF q+xyTthi1GFu/x5bCKHM3yJmPidmTIh20IefeJfUFIKSnFA75/3OPPcE5glJbwm4I7/7 jdzQ== X-Gm-Message-State: ACrzQf3RLJ4S/kABB+63TYSyXD06QbJyQO/sts7QQI4phncFFrCCVhLe 9ofiupiBbUIsDwovHCFdXjltYTWXRYS++5kcqyfxkg== X-Google-Smtp-Source: AMsMyM7THkTRaRyj2sg59JylIqlX/8u/zip8nYJhHTpaYmNVjdKnP5op7xkKDYxb5Sppxu5lSqL6mZnC7qTUOpswxzs= X-Received: by 2002:a05:6512:3241:b0:4a2:4f95:c02e with SMTP id c1-20020a056512324100b004a24f95c02emr20312626lfr.23.1668062701531; Wed, 09 Nov 2022 22:45:01 -0800 (PST) In-Reply-To: <106B8822-FE37-4590-BC77-5FB24FB0758C@gmail.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:247482 Archived-At: --000000000000c9d11905ed181ce4 Content-Type: text/plain; charset="UTF-8" I finally had some time to have a look. I don't see any more issues, thank you for the fantastic work on this. The defun-type-regexp is not enough to identify a defun in elixir this is the query I am using currently: (defvar elixir--treesit-query-defun (let ((query `((call target: (identifier) @type (arguments [ (alias) @name (identifier) @name (call target: (identifier)) @name (binary_operator left: (call target: (identifier)) @name operator: "when") ]) (:match ,elixir--definition-keywords-re @type) )))) (treesit-query-compile 'elixir query))) Regex will work in most cases I guess, but does not really deal with more complex queries for more complex cases like in elixir as there is not one type which is always the defun. elixir relies heavily on macros and different defun macros can be defined on the fly. Maybe if there is an option for using either a regex or a function? I am also not sure how forward-sexp can work with the current treesit-search-forward-goto function as it does not take into consideration the level. Is there perhaps a way to move forward/backward, but do not jump to parents or children? On Mon, 24 Oct 2022 at 22:19, Yuan Fu wrote: > > > > Thanks, I would need some time to have a proper look. The reporting > issue > > seems to have been fixed. There are some complications to identify the > > appropriate node for defun in elixir as a "call" node might, or might > not be > > defun, depending on its child identifier ( i currently have to do a > query on > > cycling up the parent ), but will try the respond in more detail in > another > > thread. > > While fixing the hanging issue, I also improved > treesit-beginning-of-defun, which now first goes backward to find a node > that matches tresit-defun-type-regexp, then goes upward and finds the > top-most parent matching treesit-defun-type-regexp, IOW, it now only stops > at top-level defun matches. Does that help with your case? > > Yuan --000000000000c9d11905ed181ce4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I finally had some time to have a look. I don= 9;t see any more issues, thank you for the fantastic work on this. The defu= n-type-regexp is not enough to identify a defun in elixir this is the query= I am using currently:

(defvar elixir--treesit-query-defun
=C2=A0= (let ((query `((call
=C2=A0 =C2=A0 =C2=A0target: (identifier) @type
= =C2=A0 =C2=A0 =C2=A0(arguments
=C2=A0 =C2=A0 =C2=A0 [
=C2=A0 =C2=A0 = =C2=A0 =C2=A0(alias) @name
=C2=A0 =C2=A0 =C2=A0 =C2=A0(identifier) @name=
=C2=A0 =C2=A0 =C2=A0 =C2=A0(call target: (identifier)) @name
=C2=A0 = =C2=A0 =C2=A0 =C2=A0(binary_operator
=C2=A0 =C2=A0 =C2=A0 =C2=A0 left: (= call target: (identifier)) @name
=C2=A0 =C2=A0 =C2=A0 =C2=A0 operator: &= quot;when")
=C2=A0 =C2=A0 =C2=A0 =C2=A0])
=C2=A0 =C2=A0 =C2=A0(:= match ,elixir--definition-keywords-re @type)
=C2=A0 =C2=A0 =C2=A0))))=C2=A0 =C2=A0 (treesit-query-compile 'elixir query)))

Reg= ex will work in most cases I guess, but does not really deal with more comp= lex queries for more complex cases like in elixir as there is not one type = which is always the defun. elixir relies heavily on macros and different de= fun macros can be defined on the fly. Maybe if there is an option for using= either a regex or a function?

I am also not sure = how forward-sexp can work with the current treesit-search-forward-goto func= tion as it does not take into consideration the level. Is there perhaps a w= ay to move forward/backward, but do not jump to parents or children?


On Mon, 24 Oct 2022 = at 22:19, Yuan Fu <casouri@gmail.com> wrote:
>
> Thanks, I would need some time to have a proper look. The reporting is= sue
> seems to have been fixed. There are some complications to identify the=
> appropriate node for defun in elixir as a "call" node might,= or might not be
> defun, depending on its child identifier ( i currently have to do a qu= ery on
> cycling up the parent ), but will try the respond in more detail in an= other
> thread.=C2=A0

While fixing the hanging issue, I also improved treesit-beginning-of-defun,= which now first goes backward to find a node that matches tresit-defun-typ= e-regexp, then goes upward and finds the top-most parent matching treesit-d= efun-type-regexp, IOW, it now only stops at top-level defun matches. Does t= hat help with your case?

Yuan
--000000000000c9d11905ed181ce4--