Juri Linkov <juri@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Received: (at 76398) by debbugs.gnu.org; 11 Mar 2025 18:22:02 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 11 14:22:02 2025 Received: from localhost ([127.0.0.1]:45566 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ts4Er-000316-Sk for submit <at> debbugs.gnu.org; Tue, 11 Mar 2025 14:22:02 -0400 Received: from relay2-d.mail.gandi.net ([217.70.183.194]:59269) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1ts4Ei-00030Y-7p; Tue, 11 Mar 2025 14:21:53 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id B738B441D8; Tue, 11 Mar 2025 18:21:38 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: Yuan Fu <casouri@HIDDEN> Subject: Re: bug#76398: treesit-aggregated-outline-predicate In-Reply-To: <4EA2FBAE-46FF-4761-9E1D-A925931645C9@HIDDEN> Organization: LINKOV.NET References: <87tt8rrwnf.fsf@HIDDEN> <87frkas7g0.fsf@HIDDEN> <87tt8nohnp.fsf@HIDDEN> <7D07FD47-D2E2-4972-9A0F-0DDF8431C2E2@HIDDEN> <87seo5eoyp.fsf@HIDDEN> <92A7D110-EA60-4F97-97BB-2DEF19F98AF8@HIDDEN> <87o6yr16dv.fsf@HIDDEN> <1A11C666-EE6E-4C5F-B564-67E0FF9CE297@HIDDEN> <87o6yjef5d.fsf@HIDDEN> <4EA2FBAE-46FF-4761-9E1D-A925931645C9@HIDDEN> Date: Tue, 11 Mar 2025 20:18:32 +0200 Message-ID: <87ldtbfn2f.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-GND-State: clean X-GND-Score: -100 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduvddvleegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufgjohhffffkfgggtgfgsehtkeertddtreejnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecuggftrfgrthhtvghrnhepieffteejgeehffejuedtiefhudekgeejteekiefgveeuheetvdefgeekkeevkedunecukfhppeeluddruddvledruddthedruddujeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeeluddruddvledruddthedruddujedphhgvlhhopehmrghilhdrghgrnhguihdrnhgvthdpmhgrihhlfhhrohhmpehjuhhriheslhhinhhkohhvrdhnvghtpdhnsggprhgtphhtthhopeegpdhrtghpthhtoheptghonhhtrhholhesuggvsggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopehvrdhpuhhpihhllhhosehgmhgrihhlrdgtohhmpdhrtghpthhtohepjeeifeelkeesuggvsggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopegtrghsohhurhhisehgmhgrihhlrdgtohhm X-GND-Sasl: juri@HIDDEN X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 76398 Cc: 76398 <at> debbugs.gnu.org, Vincenzo Pupillo <v.pupillo@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) close 76398 31.0.50 thanks >>> Combine with your reply above, it seems we need some information attached >>> to the ranges (with either overlay or text property), rather than to the >>> parser. Is that right? >> >> Maybe. One of two needs I have discovered so far is the ability >> to find the next/previous range boundary. > > I pushed some changes. Now this should be doable by searching for overlays > boundaries. Both local and non-local parsers now have an overlay that spans > the range they’re in. In the case of non-local parsers, each range it > parses gets an overlay. You can search for the comment that’s marked with > (ref:local-parser-overlay) in treesit.el to see the properties I put on the > overlays. Thanks! Searching for the next overlay now works nicely, so pushed the changes to 'treesit-outline-search'. >>> When updating ranges, we can mark the ranges covered >>> by each embed parser, and perhaps link the text prop or overlay to the >>> “parent node”. >> >> The ability to find the parent node of the range is another need. > > I think your use-case is to continue searching upwards across parser > boundary, right? I wonder if having access to the parent parser is > enough? Because once you know the parser, you can just get the > node-at-point. Yes, having access to the parent parser is enough, and everything works with the 'treesit-host-parser' overlay by finding the parent parser node with 'treesit-node-at', so pushed the changes to 'treesit-outline-level' as well.
bug-gnu-emacs@HIDDEN:bug#76398; Package emacs.
Full text available.Received: (at 76398) by debbugs.gnu.org; 11 Mar 2025 08:47:12 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 11 04:47:12 2025 Received: from localhost ([127.0.0.1]:41535 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1trvGa-0001x6-1P for submit <at> debbugs.gnu.org; Tue, 11 Mar 2025 04:47:12 -0400 Received: from mail-pl1-x635.google.com ([2607:f8b0:4864:20::635]:55618) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <casouri@HIDDEN>) id 1trvGV-0001wZ-9T for 76398 <at> debbugs.gnu.org; Tue, 11 Mar 2025 04:47:09 -0400 Received: by mail-pl1-x635.google.com with SMTP id d9443c01a7336-224171d6826so210235ad.3 for <76398 <at> debbugs.gnu.org>; Tue, 11 Mar 2025 01:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741682821; x=1742287621; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=7b1sGFNkaDfH+jtXY2yEcPrvigFdr0sAViwoNUV3r3k=; b=IToA9Q1AcBhCAIFsP4+MmV4G7r/KCic8LtLu8lIPiq1IjFXsZzTxkxCq71EeA66VTb QHEMe/rNo180UIRBGDQ+wCafipdlxvsZWk/9JpNnjLhOc4cCE7qiTDgdeU9QXkbg7QQi CceUEfgWheWVNk7B2bdCp6ZNRKe6bkdq363tUKbk0QdwEX2ODvLFCR9HC5EWaVRwjpqL gruU4fsTiEtrw1yDJZeR4C60yydo6c2WbN0Cdd7FqA4l4a+ToL3GChyxzyzlDvwH/au2 2nsIEFLktuHKYzvMC44PSkF8kJ00PVWT6CXEkJ3Fwt77GQGzWn08cIgjgtv177iMEs4o gDFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741682821; x=1742287621; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7b1sGFNkaDfH+jtXY2yEcPrvigFdr0sAViwoNUV3r3k=; b=i6UDZdEqEmkhVb/vf0rQeINpgBcYjr3VbjdUzGKxZZVil/89DsGJPmVb22s8cst1pQ 2TC5ifnMcwATULJwvlogOHb7QSoxd10VTPRhUEdUdlNgdEcf5/IlPubVOn4LtvzVfJGq zcYMpvlsC95U1ELPkCj3wajUFgkC3Chf77WtUiB18n3hOUXsytF3N51a5CnoYwAUmGBc MGj1PdxLPN2rew2CCdrMQY6TsIbAOIm4dD9hVhWU2gHVrA8gc0MELpnFd+bR+eKNCuVe 2/JiEZAoDcwGZj9MTvgLIpipxpsuqAewX8oNVe/COaMvEoLPkqNVUM/09vOFF0cNAt7G cZIQ== X-Gm-Message-State: AOJu0Yww2QcMzNaBsD14HrGBZOkdBWerCR/5646eorh1qA601svcsloa eXfmBbonfvafWAAzlgXQBzZDL8xSxt/VWtlBTlebSgf5YEXvn6cA X-Gm-Gg: ASbGncvd3G7GHke3HJQ5svoLUglzrJDfUtljhKpdyd3h061o4gkW4XC7X2boFy+yHgD lgNS8MNihUXJINiULQnh6MZKeIJe9fujxtFcdiSWCq34XmDdzhDVA+CnY82BD4LXDVTZ67OJ2HM WCqugBy1Ri7Ftv7RwgV8N790u4mJjcUw87clxRz4gV+MV7AVvMQpN3MBUuezv3s9WxuwqaNE3kg tkf3BVTMIUs+qftRIW64LgRyt7toAIlp+tI0StKxSvvGx+FfE71dfctOfmfvHwxMr2sFlRcx0y5 0zAg2j4pYcVXjFd4qNGC3p4zPDgs5m5bULO/AQpJj6wOU8Br/ro74asvaSj2fCW2y5rq X-Google-Smtp-Source: AGHT+IHoBjFyXITceuLZmCUP/3c1x+CHwupx9ZkRBqwtjw2NNJfEenJtMykQ3c/+C0zABIpB0sXFzQ== X-Received: by 2002:a05:6a21:b93:b0:1f5:58b9:6d9b with SMTP id adf61e73a8af0-1f558b978b6mr15770113637.12.1741682820756; Tue, 11 Mar 2025 01:47:00 -0700 (PDT) Received: from smtpclient.apple ([2601:646:8f81:6120:8118:a115:23f5:f03e]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-af281075eaesm9065674a12.3.2025.03.11.01.46.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Mar 2025 01:47:00 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: bug#76398: treesit-aggregated-outline-predicate From: Yuan Fu <casouri@HIDDEN> In-Reply-To: <87o6yjef5d.fsf@HIDDEN> Date: Tue, 11 Mar 2025 01:46:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4EA2FBAE-46FF-4761-9E1D-A925931645C9@HIDDEN> References: <87tt8rrwnf.fsf@HIDDEN> <87frkas7g0.fsf@HIDDEN> <87tt8nohnp.fsf@HIDDEN> <7D07FD47-D2E2-4972-9A0F-0DDF8431C2E2@HIDDEN> <87seo5eoyp.fsf@HIDDEN> <92A7D110-EA60-4F97-97BB-2DEF19F98AF8@HIDDEN> <87o6yr16dv.fsf@HIDDEN> <1A11C666-EE6E-4C5F-B564-67E0FF9CE297@HIDDEN> <87o6yjef5d.fsf@HIDDEN> To: Juri Linkov <juri@HIDDEN> X-Mailer: Apple Mail (2.3776.700.51) X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 76398 Cc: 76398 <at> debbugs.gnu.org, Vincenzo Pupillo <v.pupillo@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.3 (/) > On Mar 2, 2025, at 9:27=E2=80=AFAM, Juri Linkov <juri@HIDDEN> = wrote: >=20 >>> Maybe a better name would be = 'treesit-outline--closest-range-boundary'? >>>=20 >>> It's needed to prevent skipping the range boundaries that >>> treesit-navigate-thing does by default, e.g. instead of >>>=20 >>> from (the starting point of the navigation) >>> range_1_beg >>> range_1_end >>> to (the ending point of the navigation) >=20 > But currently handling a local parser is not possible in the above = function. > For example, I tried: >=20 > (mapcar #'treesit-parser-included-ranges > (append (treesit-parser-list) > (treesit-local-parsers-at (point)))) >=20 > But it's position-dependent and can't find the next local-parser > when the position of point is before the start of the local-parser. >=20 >>> Like you noticed, we need to check ranges, not parsers anyway, >>> so treesit-local-parsers-at can't help here. >>=20 >> Combine with your reply above, it seems we need some information = attached >> to the ranges (with either overlay or text property), rather than to = the >> parser. Is that right? >=20 > Maybe. One of two needs I have discovered so far is the ability > to find the next/previous range boundary. I pushed some changes. Now this should be doable by searching for = overlays boundaries. Both local and non-local parsers now have an = overlay that spans the range they=E2=80=99re in. In the case of = non-local parsers, each range it parses gets an overlay. You can search = for the comment that=E2=80=99s marked with (ref:local-parser-overlay) in = treesit.el to see the properties I put on the overlays. >> When updating ranges, we can mark the ranges covered >> by each embed parser, and perhaps link the text prop or overlay to = the >> =E2=80=9Cparent node=E2=80=9D. >=20 > The ability to find the parent node of the range is another need. I think your use-case is to continue searching upwards across parser = boundary, right? I wonder if having access to the parent parser is = enough? Because once you know the parser, you can just get the = node-at-point. >>>>>> I bring this up because this tree structure would=E2=80=99ve >>>>>> solved your problem here as well, once we have it. >=20 > A tree of ranges (including ranges of local parsers) > would solve the problem indeed. This should be possible now by going over the overlays at point and find = the parser that has a -1 embed level. There should only one parser with = -1 embed level. >> I=E2=80=99ve mostly worked out arbitrary nesting of embedded parsers. >> I tested with markdown -> javascript -> jsdoc, and it seems to work >> fine. What I=E2=80=99m not sure about right now is the navigation = part. >=20 > I tested on mhtml-ts-mode -> javascript -> jsdoc and > (mapcar 'treesit-parser-embed-level (treesit-local-parsers-at = (point))) > correctly returns (2). Whereas > (mapcar 'treesit-parser-parent-node (treesit-local-parsers-at = (point))) > returns (nil). >=20 > BTW, while deleting a jsdoc block I get such backtrace: >=20 > Debugger entered--Lisp error: (treesit-parser-deleted #<treesit-parser = for jsdoc>) > treesit-node-on(1 202 #<treesit-parser for jsdoc>) > treesit--explorer-refresh() > apply(treesit--explorer-refresh nil) > timer-event-handler([t ... >=20 > and while editing a jsdoc block (inserting a newline before it): >=20 > Debugger entered--Lisp error: (treesit-no-parser jsdoc) > treesit-buffer-root-node(jsdoc) > treesit-node-on(60 60) > treesit--indent-1() > treesit-indent() > indent-according-to-mode() > electric-indent-post-self-insert-function() > newline(nil 1) > funcall-interactively(newline nil 1) > command-execute(newline) Thanks, these should be fixed now. Yuan=
bug-gnu-emacs@HIDDEN:bug#76398; Package emacs.
Full text available.
Received: (at 76398) by debbugs.gnu.org; 2 Mar 2025 17:52:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 02 12:52:38 2025
Received: from localhost ([127.0.0.1]:34567 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tonUU-0003sj-4T
for submit <at> debbugs.gnu.org; Sun, 02 Mar 2025 12:52:38 -0500
Received: from relay2-d.mail.gandi.net ([217.70.183.194]:42637)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1tonUJ-0003qs-8f
for 76398 <at> debbugs.gnu.org; Sun, 02 Mar 2025 12:52:27 -0500
Received: by mail.gandi.net (Postfix) with ESMTPSA id AA6C444164;
Sun, 2 Mar 2025 17:52:19 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Yuan Fu <casouri@HIDDEN>
Subject: Re: bug#76398: treesit-aggregated-outline-predicate
In-Reply-To: <1A11C666-EE6E-4C5F-B564-67E0FF9CE297@HIDDEN>
Organization: LINKOV.NET
References: <87tt8rrwnf.fsf@HIDDEN> <87frkas7g0.fsf@HIDDEN>
<87tt8nohnp.fsf@HIDDEN>
<7D07FD47-D2E2-4972-9A0F-0DDF8431C2E2@HIDDEN>
<87seo5eoyp.fsf@HIDDEN>
<92A7D110-EA60-4F97-97BB-2DEF19F98AF8@HIDDEN>
<87o6yr16dv.fsf@HIDDEN>
<1A11C666-EE6E-4C5F-B564-67E0FF9CE297@HIDDEN>
Date: Sun, 02 Mar 2025 19:27:42 +0200
Message-ID: <87o6yjef5d.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-GND-State: clean
X-GND-Score: -100
X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdelieekiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfitefpfffkpdcuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefujghofhffkfgfgggtgfesthekredttderjeenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucggtffrrghtthgvrhhnpeeiffetjeegheffjeeutdeihfdukeegjeetkeeigfevueehtedvfeegkeekveekudenucfkphepledurdduvdelrddutdehrdduudejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepledurdduvdelrddutdehrdduudejpdhhvghlohepmhgrihhlrdhgrghnughirdhnvghtpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhgspghrtghpthhtohepfedprhgtphhtthhopehvrdhpuhhpihhllhhosehgmhgrihhlrdgtohhmpdhrtghpthhtohepjeeifeelkeesuggvsggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopegtrghsohhurhhisehgmhgrihhlrdgtohhm
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 76398
Cc: 76398 <at> debbugs.gnu.org, Vincenzo Pupillo <v.pupillo@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
>> Maybe a better name would be 'treesit-outline--closest-range-boundary'?
>>
>> It's needed to prevent skipping the range boundaries that
>> treesit-navigate-thing does by default, e.g. instead of
>>
>> from (the starting point of the navigation)
>> range_1_beg
>> range_1_end
>> to (the ending point of the navigation)
But currently handling a local parser is not possible in the above function.
For example, I tried:
(mapcar #'treesit-parser-included-ranges
(append (treesit-parser-list)
(treesit-local-parsers-at (point))))
But it's position-dependent and can't find the next local-parser
when the position of point is before the start of the local-parser.
>> Like you noticed, we need to check ranges, not parsers anyway,
>> so treesit-local-parsers-at can't help here.
>
> Combine with your reply above, it seems we need some information attached
> to the ranges (with either overlay or text property), rather than to the
> parser. Is that right?
Maybe. One of two needs I have discovered so far is the ability
to find the next/previous range boundary.
> When updating ranges, we can mark the ranges covered
> by each embed parser, and perhaps link the text prop or overlay to the
> “parent node”.
The ability to find the parent node of the range is another need.
>>>>> I bring this up because this tree structure would’ve
>>>>> solved your problem here as well, once we have it.
A tree of ranges (including ranges of local parsers)
would solve the problem indeed.
> I’ve mostly worked out arbitrary nesting of embedded parsers.
> I tested with markdown -> javascript -> jsdoc, and it seems to work
> fine. What I’m not sure about right now is the navigation part.
I tested on mhtml-ts-mode -> javascript -> jsdoc and
(mapcar 'treesit-parser-embed-level (treesit-local-parsers-at (point)))
correctly returns (2). Whereas
(mapcar 'treesit-parser-parent-node (treesit-local-parsers-at (point)))
returns (nil).
BTW, while deleting a jsdoc block I get such backtrace:
Debugger entered--Lisp error: (treesit-parser-deleted #<treesit-parser for jsdoc>)
treesit-node-on(1 202 #<treesit-parser for jsdoc>)
treesit--explorer-refresh()
apply(treesit--explorer-refresh nil)
timer-event-handler([t ...
and while editing a jsdoc block (inserting a newline before it):
Debugger entered--Lisp error: (treesit-no-parser jsdoc)
treesit-buffer-root-node(jsdoc)
treesit-node-on(60 60)
treesit--indent-1()
treesit-indent()
indent-according-to-mode()
electric-indent-post-self-insert-function()
newline(nil 1)
funcall-interactively(newline nil 1)
command-execute(newline)
bug-gnu-emacs@HIDDEN:bug#76398; Package emacs.
Full text available.Received: (at 76398) by debbugs.gnu.org; 28 Feb 2025 03:10:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 27 22:10:22 2025 Received: from localhost ([127.0.0.1]:42007 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tnqlZ-0007wZ-It for submit <at> debbugs.gnu.org; Thu, 27 Feb 2025 22:10:22 -0500 Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]:45468) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <casouri@HIDDEN>) id 1tnqlW-0007r0-Ut for 76398 <at> debbugs.gnu.org; Thu, 27 Feb 2025 22:10:20 -0500 Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-2fe8c35b6cbso2667226a91.3 for <76398 <at> debbugs.gnu.org>; Thu, 27 Feb 2025 19:10:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740712213; x=1741317013; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=eimFJiwBeZS/JfPuULQEJhrLLVrGmtyl7woXL0mUmdM=; b=GwuvmSSvlsONv5JEcPyz+EfjqczuyW0yIspd9Ux8ZLDbPoDel3UTMLda0uMgGuUTuT P4TCD1HqKu30ftP735ilqTqq/1t8N006GsgvS9ksbNOHuwIz6MQ0Q+Lg1vrYSk91KP2F yvITkkZR5XP3Gc8/jOWfxPTgr8azPF90SbMaWDKTiPwM0oLzcNBFrnwuhNDwaIRZXBPg lmctJkxmLYandaBMFTjfezCXLPG3knSmrCJ5u1v7vq7I0izZ6l3P6Z9X15wrZJr4n3Zq K1ysfgpC+qDg+uzyP/0rfNPso0A1d2+HCRULOyYvJqSCzMsDy2IPKH1KFaxaLbz0kfcE lM0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740712213; x=1741317013; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=eimFJiwBeZS/JfPuULQEJhrLLVrGmtyl7woXL0mUmdM=; b=pGf+TdXxglhN3NDTRt2XKXkyS0mLY6bx0Uu5OsquMlBcEkPGy9lr4kUAovTu6mrse4 NFoQAdNzOw9M/3p1nqZNr5V9sKXRFITIiDsZ0wKnzNH7+sXRAPeVw0gSoop7WApbnd3C JJeYZJKJFYSJRKrT8VckN6NKG263xFNxTmUo3Nw0vlpA1nYnDBOiJoyhqwhEkgNo6oHs oGndOlfxjwinA+Iwea+Fsp/pggtnWDFFo09Xjr46bTegOBk+xvd0s0xMkVkq72FVqJv3 MpDGtmbvn7SDiRPekntOG5dJqjztN1P/jwwjRRZ+0Mgb5feWbnAeH/1KGDLD9hwxJ2rR wyqA== X-Gm-Message-State: AOJu0YyreCW38JXy32Q++GVZcZzM7ojIaG6IyyCkorjVdxMBb+XB7OJC lgWSBzJTHxtABt2YIee/p7cGoPe6NYJkoFTaqtGsNnmKqSy8DI2j X-Gm-Gg: ASbGncugtjirF/S0ujdoryVhO/Om0ng8xMzr84OXzeC5wVRatg9NNYh0mkSnRWi50bK yc8G3ayFHg6aeQg+uHny5oBDGd28rNLZ/hpVvtLNkxtvd3SViM6wToycLDsdQ95t2EY1Hv7mgTU OpSzZdbhgbRUxeiSNVJ9a2V8kMGyI9kDCjZNIInG7ixrDl2jCgHeT6yPa/f5E0fc1x3IcQTKAPC eVSI7RJ08HVwMilG3/Up9F2cwZ2xIwm3oUL844TcJcMPcia/1S2M0K6+Yuy3rZwUOIptaBHoRQj tQ8RazcbJycs3GauDd/5jAE/f2ed7XIbHiCtd7En/NZDEWRouw== X-Google-Smtp-Source: AGHT+IGHblVAbgFoKhhKCxhtH2KrTM5AMPq2XyJBumdAqyggrVUJgpjxbYJae9a0kltP6XMWf8hkHg== X-Received: by 2002:a17:90a:d605:b0:2fe:afa7:eaf8 with SMTP id 98e67ed59e1d1-2febab3a26cmr2672383a91.13.1740712212434; Thu, 27 Feb 2025 19:10:12 -0800 (PST) Received: from smtpclient.apple ([2601:646:8f81:6120:694a:b28e:c9a5:6e3e]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2fea67530dfsm2609864a91.8.2025.02.27.19.10.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Feb 2025 19:10:11 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: bug#76398: treesit-aggregated-outline-predicate From: Yuan Fu <casouri@HIDDEN> In-Reply-To: <87o6yr16dv.fsf@HIDDEN> Date: Thu, 27 Feb 2025 19:10:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1A11C666-EE6E-4C5F-B564-67E0FF9CE297@HIDDEN> References: <87tt8rrwnf.fsf@HIDDEN> <87frkas7g0.fsf@HIDDEN> <87tt8nohnp.fsf@HIDDEN> <7D07FD47-D2E2-4972-9A0F-0DDF8431C2E2@HIDDEN> <87seo5eoyp.fsf@HIDDEN> <92A7D110-EA60-4F97-97BB-2DEF19F98AF8@HIDDEN> <87o6yr16dv.fsf@HIDDEN> To: Juri Linkov <juri@HIDDEN> X-Mailer: Apple Mail (2.3776.700.51) X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 76398 Cc: 76398 <at> debbugs.gnu.org, Vincenzo Pupillo <v.pupillo@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.3 (/) > On Feb 24, 2025, at 11:37=E2=80=AFAM, Juri Linkov <juri@HIDDEN> = wrote: >=20 >>>>>>> So this patch helps 'treesit-outline-search' to get out of the = local parser >>>>>>> to the primary parser to continue search for the next outline = predicate. >>>>>>>=20 >>>>>>> 'treesit-outline-level' should do the same, but currently I = can't find >>>>>>> a suitable function to break out of embedded confinement >>>>>>> and get the host node that contains the guest ranges. >>>>>>> I mean that e.g. (treesit-parser-root-node (treesit-node-parser = node)) >>>>>>> can get the root node of the local parser, but how to get its = parent node >>>>>>> in the primary parser? It's understandable that = treesit-node-parent >>>>>>> doesn't go out of its parser. But maybe there is another = function? >>>>>>> If such function doesn't exist, this is fine, then could find = that >>>>>>> node manually by calculating from = treesit-parser-included-ranges. >>>>>>=20 >>>>>> Maybe we need two new primitives: >>>>>>=20 >>>>>> (treesit-next-parser-boundary POS) >>>>>> (treesit-prev-parser-boundary POS) >>>>>=20 >>>>> Now pushed as 'treesit-closest-parser-boundary'. >>>>=20 >>>> Hold on, let=E2=80=99s not get ahead of ourselves. First of all, = the name is not >>>> very descriptive IMO it actually finds range boundary, not parser = boundary; >>>> and the docstring mentions local parser while the function itself = doesn=E2=80=99t >>>> really involve local parsers=E2=80=94it just checks parser ranges. = It can be used >>>> for getting out of local parsers, yes, but that=E2=80=99s a = use-case, not what it >>>> does. So if we want to add this function to the public API set for >>>> tree-sitter, it needs a better docstring. (And at the moment I have = doubt >>>> on its general usefulness.) >>>=20 >>> I assumed that this function will not remain in the final >>> implementation of this feature. I added it temporarily >>> to get the embedded outlines into a working state. >>=20 >> Great. Then let=E2=80=99s use double dash and maybe even add some = comments to explain that, WDYT? >=20 > Maybe a better name would be = 'treesit-outline--closest-range-boundary'? >=20 > It's needed to prevent skipping the range boundaries that > treesit-navigate-thing does by default, e.g. instead of >=20 > from (the starting point of the navigation) > range_1_beg > range_1_end > to (the ending point of the navigation) >=20 > we need to stop inside the next range and search inside from its = beginning: >=20 > from > range_1_beg > to > range_1_end >=20 > Another case it that when inside a local range, treesit-navigate-thing > returns nil, but need to go outside the local range, and continue the = search: >=20 > range_1_beg > from > range_1_end > to >=20 >>>> More over, is this even necessary? Why do we need to go over all = the >>>> ranges for all the parsers to get out of a local parser? I thought = we >>>> can just get the local parser and get it=E2=80=99s range? >>>=20 >>> I tried to use treesit-local-parsers-at, but it always returns nil. >>=20 >> That=E2=80=99s probably because the major mode you=E2=80=99re testing = with doesn=E2=80=99t use >> local parser for the embedded language. I=E2=80=99ll add a function = to get the >> =E2=80=9Cparent node=E2=80=9D, that should solve your problem here. >=20 > Like you noticed, we need to check ranges, not parsers anyway, > so treesit-local-parsers-at can't help here. Combine with your reply above, it seems we need some information = attached to the ranges (with either overlay or text property), rather = than to the parser. Is that right? When updating ranges, we can mark the = ranges covered by each embed parser, and perhaps link the text prop or = overlay to the =E2=80=9Cparent node=E2=80=9D. >>>>>> (treesit-upper-parser-node POS) >>>>>=20 >>>>> Addition of 'treesit-upper-parser-node' is underway that should >>>>> be used in 'treesit-up-list' as well. >>>>=20 >>>> And if we need to get the =E2=80=9Cparent node=E2=80=9D of a local = parser, we can do it in >>>> much nicer ways. We can record the parent node when creating the = local >>>> parser, by either adding a field to the parser object, or record it = in >>>> a local database, or even just save it in the text property = alongside the >>>> local parser. Let=E2=80=99s take some time and think of the best = way to solve >>>> this. >>>=20 >>> Now I improved treesit-outline-level as well without adding >>> new functions. Everything works now, so we can do more >>> refactoring without introducing regressions. >>>=20 >>>> Whatever you have in mind, I suspect that it wouldn=E2=80=99t work = if there >>>> are more than one layer of nesting of parsers, ie, what if you want = to get >>>> out of a embedded (local) parser=E2=80=99s embedded parser? >>>=20 >>> The current implementation in treesit-outline-level works with any = depth >>> of nested parsers. But the current solution is quite fragile. So = we need >>> to find a better way such as recording the parent parser node = somewhere. >=20 > Actually, here as well we need a parent node for the range, not the = parser. > Maybe the range should be a special object like the parser is? >=20 >>>> On the same note, we actually need some proper tree structure for = the >>>> primary parser - local parser relationship, because there can be = more than >>>> one layer. What we currently have doesn=E2=80=99t handle this well = (font-lock and >>>> indentation). It=E2=80=99s a real use case, someone requested for = this for the Perl >>>> (or Haskell?) mode, and imagine a rust buffer embeds a markdown = comment >>>> which embeds rust code examples. I bring this up because this tree >>>> structure would=E2=80=99ve solved your problem here as well, once = we have it. >>>=20 >>> Agreed, this needs a better design. >>=20 >> Cool, working on it. >=20 > Thanks. I=E2=80=99ve mostly worked out arbitrary nesting of embedded parsers. I = tested with markdown -> javascript -> jsdoc, and it seems to work fine. = What I=E2=80=99m not sure about right now is the navigation part. Yuan=
bug-gnu-emacs@HIDDEN:bug#76398; Package emacs.
Full text available.Received: (at 76398) by debbugs.gnu.org; 24 Feb 2025 19:40:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 24 14:40:20 2025 Received: from localhost ([127.0.0.1]:42745 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tmeJQ-0006b3-0t for submit <at> debbugs.gnu.org; Mon, 24 Feb 2025 14:40:20 -0500 Received: from relay5-d.mail.gandi.net ([2001:4b98:dc4:8::225]:44171) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1tmeJM-0006aF-Tv for 76398 <at> debbugs.gnu.org; Mon, 24 Feb 2025 14:40:18 -0500 Received: by mail.gandi.net (Postfix) with ESMTPSA id E551C44349; Mon, 24 Feb 2025 19:40:08 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: Yuan Fu <casouri@HIDDEN> Subject: Re: bug#76398: treesit-aggregated-outline-predicate In-Reply-To: <92A7D110-EA60-4F97-97BB-2DEF19F98AF8@HIDDEN> Organization: LINKOV.NET References: <87tt8rrwnf.fsf@HIDDEN> <87frkas7g0.fsf@HIDDEN> <87tt8nohnp.fsf@HIDDEN> <7D07FD47-D2E2-4972-9A0F-0DDF8431C2E2@HIDDEN> <87seo5eoyp.fsf@HIDDEN> <92A7D110-EA60-4F97-97BB-2DEF19F98AF8@HIDDEN> Date: Mon, 24 Feb 2025 21:37:16 +0200 Message-ID: <87o6yr16dv.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-GND-State: clean X-GND-Score: 0 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdejleeiiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfitefpfffkpdcuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedtudenucenucfjughrpefhvfevufgjohhffffkfgggtgfgsehtkeertddtreejnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecuggftrfgrthhtvghrnhepieffteejgeehffejuedtiefhudekgeejteekiefgveeuheetvdefgeekkeevkedunecukfhppeeluddruddvledruddthedruddujeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeeluddruddvledruddthedruddujedphhgvlhhopehmrghilhdrghgrnhguihdrnhgvthdpmhgrihhlfhhrohhmpehjuhhriheslhhinhhkohhvrdhnvghtpdhnsggprhgtphhtthhopeefpdhrtghpthhtohepvhdrphhuphhilhhlohesghhmrghilhdrtghomhdprhgtphhtthhopeejieefleekseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtoheptggrshhouhhrihesghhmrghilhdrtghomh X-GND-Sasl: juri@HIDDEN X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 76398 Cc: 76398 <at> debbugs.gnu.org, v.pupillo@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) >>>>>> So this patch helps 'treesit-outline-search' to get out of the local parser >>>>>> to the primary parser to continue search for the next outline predicate. >>>>>> >>>>>> 'treesit-outline-level' should do the same, but currently I can't find >>>>>> a suitable function to break out of embedded confinement >>>>>> and get the host node that contains the guest ranges. >>>>>> I mean that e.g. (treesit-parser-root-node (treesit-node-parser node)) >>>>>> can get the root node of the local parser, but how to get its parent node >>>>>> in the primary parser? It's understandable that treesit-node-parent >>>>>> doesn't go out of its parser. But maybe there is another function? >>>>>> If such function doesn't exist, this is fine, then could find that >>>>>> node manually by calculating from treesit-parser-included-ranges. >>>>> >>>>> Maybe we need two new primitives: >>>>> >>>>> (treesit-next-parser-boundary POS) >>>>> (treesit-prev-parser-boundary POS) >>>> >>>> Now pushed as 'treesit-closest-parser-boundary'. >>> >>> Hold on, let’s not get ahead of ourselves. First of all, the name is not >>> very descriptive IMO it actually finds range boundary, not parser boundary; >>> and the docstring mentions local parser while the function itself doesn’t >>> really involve local parsers—it just checks parser ranges. It can be used >>> for getting out of local parsers, yes, but that’s a use-case, not what it >>> does. So if we want to add this function to the public API set for >>> tree-sitter, it needs a better docstring. (And at the moment I have doubt >>> on its general usefulness.) >> >> I assumed that this function will not remain in the final >> implementation of this feature. I added it temporarily >> to get the embedded outlines into a working state. > > Great. Then let’s use double dash and maybe even add some comments to explain that, WDYT? Maybe a better name would be 'treesit-outline--closest-range-boundary'? It's needed to prevent skipping the range boundaries that treesit-navigate-thing does by default, e.g. instead of from (the starting point of the navigation) range_1_beg range_1_end to (the ending point of the navigation) we need to stop inside the next range and search inside from its beginning: from range_1_beg to range_1_end Another case it that when inside a local range, treesit-navigate-thing returns nil, but need to go outside the local range, and continue the search: range_1_beg from range_1_end to >>> More over, is this even necessary? Why do we need to go over all the >>> ranges for all the parsers to get out of a local parser? I thought we >>> can just get the local parser and get it’s range? >> >> I tried to use treesit-local-parsers-at, but it always returns nil. > > That’s probably because the major mode you’re testing with doesn’t use > local parser for the embedded language. I’ll add a function to get the > “parent node”, that should solve your problem here. Like you noticed, we need to check ranges, not parsers anyway, so treesit-local-parsers-at can't help here. >>>>> (treesit-upper-parser-node POS) >>>> >>>> Addition of 'treesit-upper-parser-node' is underway that should >>>> be used in 'treesit-up-list' as well. >>> >>> And if we need to get the “parent node” of a local parser, we can do it in >>> much nicer ways. We can record the parent node when creating the local >>> parser, by either adding a field to the parser object, or record it in >>> a local database, or even just save it in the text property alongside the >>> local parser. Let’s take some time and think of the best way to solve >>> this. >> >> Now I improved treesit-outline-level as well without adding >> new functions. Everything works now, so we can do more >> refactoring without introducing regressions. >> >>> Whatever you have in mind, I suspect that it wouldn’t work if there >>> are more than one layer of nesting of parsers, ie, what if you want to get >>> out of a embedded (local) parser’s embedded parser? >> >> The current implementation in treesit-outline-level works with any depth >> of nested parsers. But the current solution is quite fragile. So we need >> to find a better way such as recording the parent parser node somewhere. Actually, here as well we need a parent node for the range, not the parser. Maybe the range should be a special object like the parser is? >>> On the same note, we actually need some proper tree structure for the >>> primary parser - local parser relationship, because there can be more than >>> one layer. What we currently have doesn’t handle this well (font-lock and >>> indentation). It’s a real use case, someone requested for this for the Perl >>> (or Haskell?) mode, and imagine a rust buffer embeds a markdown comment >>> which embeds rust code examples. I bring this up because this tree >>> structure would’ve solved your problem here as well, once we have it. >> >> Agreed, this needs a better design. > > Cool, working on it. Thanks.
bug-gnu-emacs@HIDDEN:bug#76398; Package emacs.
Full text available.Received: (at 76398) by debbugs.gnu.org; 24 Feb 2025 06:48:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 24 01:48:09 2025 Received: from localhost ([127.0.0.1]:38141 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tmSG9-0003dd-AN for submit <at> debbugs.gnu.org; Mon, 24 Feb 2025 01:48:09 -0500 Received: from mail-pl1-x632.google.com ([2607:f8b0:4864:20::632]:53443) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <casouri@HIDDEN>) id 1tmSG6-0003d0-Nf for 76398 <at> debbugs.gnu.org; Mon, 24 Feb 2025 01:48:07 -0500 Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-2211cd4463cso76416575ad.2 for <76398 <at> debbugs.gnu.org>; Sun, 23 Feb 2025 22:48:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740379680; x=1740984480; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ApWuigU9F8Sb1nRJRk4s78O0chbazMk+S2Zi4spUz90=; b=fQ+vDsLUI4O6mqhURLFaE1TXrTm5H5L/LhFpc4YT5gIWKAiHr9SvElN7kJxVxwIOMa OkbqIF3joCGcuEtPLUS05a5jYGd0AbGXjrY7nDlXJmoa/jly4cDiIaU8s1iHT8aJZ8Y7 f3tiMTUget9agHouqKFFCX9Wwe0Pp6wCtOOGcPu8exoiQb/8q3kUfjEHMb1dlglWZHnb 1flxZJdaL5jJ4MK7oI1YHfDtZN6QJnZa38+urzLsNNlTM7gfgVVWOpSEK5Y0t/tHejZd VQCkxPJCZOJYJ3CtqWIDX2BqEqgt4GSAxZF9lc9eA4dpeJvVY+sbuTGZSdqN7iFaP+An vdBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740379680; x=1740984480; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ApWuigU9F8Sb1nRJRk4s78O0chbazMk+S2Zi4spUz90=; b=UnIGbanXVeaXrs+owrZqxDyRhLrkAElncfADaMPs1tLB0DG0IjZjFnmQcqQTfKdneo 4XaqTXFUabGsVqzetbie3gWV/yjMNLlfYcJEhnCyB/ICTJltU17ka6DceOm5AoiLMmm+ BsIhdOXPTb6GjIbztisO3pWfqFMYiWbH6FBbWjeupltCg3h/1R7dBceD9jAJm+VUXeQw QJ+y2GQqf/Fv0wi1efdoWBqJxq+4BV5G3O8eugszxI6QuVolQxlpZQfKCPsCaigAitKh J+SuPB7kFYFAGimDXEBXCLWm8lk9OkP0tehoEb7UjgH2sz07vFgZU16QnlSqvSTV5qdU QWmg== X-Gm-Message-State: AOJu0YyfNQ6uXzfERW29pyvoolCHbhvb9h0GuBwIBYEQynepbfMYUDLv gqGNNAm7zjzUr+KxztcSxvvh3hQXn6T+7aQ/V3VOEgEr0cob4yBS X-Gm-Gg: ASbGncubfwTgbTvX503U7aW9xryEETA1IJBQCS11vurY8iQWmRDVG+/eq7MldEfPsM3 AO6OYfMomTnW8STe1JSEFeAUIjzxNxYcR6aT/bej7UnIExIJp0hnJTDvs5VuMBd8A09cSg04bRN scFZLeRWby2WUdm+60tmVFagOf6ehmP60aDS67Cn6Rv4JuVytwJ6qj9XDgw0uq1KfOw9TdOxKW9 S9KTNe0sGYn03PfKbduqujd/Bjblzt+2XlMkScwGM/vZlIuFoKOc3kloI1TL9v0j8yYUXZqocDJ 714Db5B8TTF3l+kvqTDKBbi8vlLrsgUBbfUd4u5j5iXbGorQug== X-Google-Smtp-Source: AGHT+IEPzuTVpEGAiAh7kfL90W1Q1krGyrNsBCxvpwrD4WTFwtB2iJyGvBFFRq+BPL7I/ZCb6itTig== X-Received: by 2002:a17:90b:3b4a:b0:2f9:9ddd:689b with SMTP id 98e67ed59e1d1-2fce7b2627fmr17316464a91.22.1740379680332; Sun, 23 Feb 2025 22:48:00 -0800 (PST) Received: from smtpclient.apple ([2601:646:8f81:6120:2cc1:c36b:7bb8:5b37]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2fceb04bf70sm5714080a91.16.2025.02.23.22.47.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Feb 2025 22:47:59 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: bug#76398: treesit-aggregated-outline-predicate From: Yuan Fu <casouri@HIDDEN> In-Reply-To: <87seo5eoyp.fsf@HIDDEN> Date: Sun, 23 Feb 2025 22:47:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <92A7D110-EA60-4F97-97BB-2DEF19F98AF8@HIDDEN> References: <87tt8rrwnf.fsf@HIDDEN> <87frkas7g0.fsf@HIDDEN> <87tt8nohnp.fsf@HIDDEN> <7D07FD47-D2E2-4972-9A0F-0DDF8431C2E2@HIDDEN> <87seo5eoyp.fsf@HIDDEN> To: Juri Linkov <juri@HIDDEN> X-Mailer: Apple Mail (2.3776.700.51) X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 76398 Cc: 76398 <at> debbugs.gnu.org, v.pupillo@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.3 (/) > On Feb 22, 2025, at 11:53=E2=80=AFAM, Juri Linkov <juri@HIDDEN> = wrote: >=20 >>>>> So this patch helps 'treesit-outline-search' to get out of the = local parser >>>>> to the primary parser to continue search for the next outline = predicate. >>>>>=20 >>>>> 'treesit-outline-level' should do the same, but currently I can't = find >>>>> a suitable function to break out of embedded confinement >>>>> and get the host node that contains the guest ranges. >>>>> I mean that e.g. (treesit-parser-root-node (treesit-node-parser = node)) >>>>> can get the root node of the local parser, but how to get its = parent node >>>>> in the primary parser? It's understandable that = treesit-node-parent >>>>> doesn't go out of its parser. But maybe there is another = function? >>>>> If such function doesn't exist, this is fine, then could find that >>>>> node manually by calculating from treesit-parser-included-ranges. >>>>=20 >>>> Maybe we need two new primitives: >>>>=20 >>>> (treesit-next-parser-boundary POS) >>>> (treesit-prev-parser-boundary POS) >>>=20 >>> Now pushed as 'treesit-closest-parser-boundary'. >>=20 >> Hold on, let=E2=80=99s not get ahead of ourselves. First of all, the = name is not >> very descriptive IMO it actually finds range boundary, not parser = boundary; >> and the docstring mentions local parser while the function itself = doesn=E2=80=99t >> really involve local parsers=E2=80=94it just checks parser ranges. It = can be used >> for getting out of local parsers, yes, but that=E2=80=99s a use-case, = not what it >> does. So if we want to add this function to the public API set for >> tree-sitter, it needs a better docstring. (And at the moment I have = doubt >> on its general usefulness.) >=20 > I assumed that this function will not remain in the final > implementation of this feature. I added it temporarily > to get the embedded outlines into a working state. Great. Then let=E2=80=99s use double dash and maybe even add some = comments to explain that, WDYT? >=20 >> More over, is this even necessary? Why do we need to go over all the >> ranges for all the parsers to get out of a local parser? I thought = we >> can just get the local parser and get it=E2=80=99s range? >=20 > I tried to use treesit-local-parsers-at, but it always returns nil. That=E2=80=99s probably because the major mode you=E2=80=99re testing = with doesn=E2=80=99t use local parser for the embedded language. I=E2=80=99= ll add a function to get the =E2=80=9Cparent node=E2=80=9D, that should = solve your problem here. >=20 >>>> (treesit-upper-parser-node POS) >>>=20 >>> Addition of 'treesit-upper-parser-node' is underway that should >>> be used in 'treesit-up-list' as well. >>=20 >> And if we need to get the =E2=80=9Cparent node=E2=80=9D of a local = parser, we can do it in >> much nicer ways. We can record the parent node when creating the = local >> parser, by either adding a field to the parser object, or record it = in >> a local database, or even just save it in the text property alongside = the >> local parser. Let=E2=80=99s take some time and think of the best way = to solve >> this. >=20 > Now I improved treesit-outline-level as well without adding > new functions. Everything works now, so we can do more > refactoring without introducing regressions. >=20 >> Whatever you have in mind, I suspect that it wouldn=E2=80=99t work if = there >> are more than one layer of nesting of parsers, ie, what if you want = to get >> out of a embedded (local) parser=E2=80=99s embedded parser? >=20 > The current implementation in treesit-outline-level works with any = depth > of nested parsers. But the current solution is quite fragile. So we = need > to find a better way such as recording the parent parser node = somewhere. >=20 >> On the same note, we actually need some proper tree structure for the >> primary parser - local parser relationship, because there can be more = than >> one layer. What we currently have doesn=E2=80=99t handle this well = (font-lock and >> indentation). It=E2=80=99s a real use case, someone requested for = this for the Perl >> (or Haskell?) mode, and imagine a rust buffer embeds a markdown = comment >> which embeds rust code examples. I bring this up because this tree >> structure would=E2=80=99ve solved your problem here as well, once we = have it. >=20 > Agreed, this needs a better design. Cool, working on it. Yuan=
bug-gnu-emacs@HIDDEN:bug#76398; Package emacs.
Full text available.Received: (at 76398) by debbugs.gnu.org; 22 Feb 2025 19:55:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 22 14:55:56 2025 Received: from localhost ([127.0.0.1]:57270 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tlvbP-0004WG-MQ for submit <at> debbugs.gnu.org; Sat, 22 Feb 2025 14:55:56 -0500 Received: from relay6-d.mail.gandi.net ([2001:4b98:dc4:8::226]:46765) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1tlvbM-0004Vz-NK for 76398 <at> debbugs.gnu.org; Sat, 22 Feb 2025 14:55:53 -0500 Received: by mail.gandi.net (Postfix) with ESMTPSA id 98EAB442CC; Sat, 22 Feb 2025 19:55:42 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: Yuan Fu <casouri@HIDDEN> Subject: Re: bug#76398: treesit-aggregated-outline-predicate In-Reply-To: <7D07FD47-D2E2-4972-9A0F-0DDF8431C2E2@HIDDEN> Organization: LINKOV.NET References: <87tt8rrwnf.fsf@HIDDEN> <87frkas7g0.fsf@HIDDEN> <87tt8nohnp.fsf@HIDDEN> <7D07FD47-D2E2-4972-9A0F-0DDF8431C2E2@HIDDEN> Date: Sat, 22 Feb 2025 21:53:02 +0200 Message-ID: <87seo5eoyp.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-GND-State: clean X-GND-Score: 0 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdejfeekvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfitefpfffkpdcuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedtudenucenucfjughrpefhvfevufgjohhffffkfgggtgfgsehtkeertddtreejnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecuggftrfgrthhtvghrnhepieffteejgeehffejuedtiefhudekgeejteekiefgveeuheetvdefgeekkeevkedunecukfhppeeluddruddvledruddthedruddujeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeeluddruddvledruddthedruddujedphhgvlhhopehmrghilhdrghgrnhguihdrnhgvthdpmhgrihhlfhhrohhmpehjuhhriheslhhinhhkohhvrdhnvghtpdhnsggprhgtphhtthhopeefpdhrtghpthhtohepvhdrphhuphhilhhlohesghhmrghilhdrtghomhdprhgtphhtthhopeejieefleekseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtoheptggrshhouhhrihesghhmrghilhdrtghomh X-GND-Sasl: juri@HIDDEN X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 76398 Cc: 76398 <at> debbugs.gnu.org, v.pupillo@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) >>>> So this patch helps 'treesit-outline-search' to get out of the local parser >>>> to the primary parser to continue search for the next outline predicate. >>>> >>>> 'treesit-outline-level' should do the same, but currently I can't find >>>> a suitable function to break out of embedded confinement >>>> and get the host node that contains the guest ranges. >>>> I mean that e.g. (treesit-parser-root-node (treesit-node-parser node)) >>>> can get the root node of the local parser, but how to get its parent node >>>> in the primary parser? It's understandable that treesit-node-parent >>>> doesn't go out of its parser. But maybe there is another function? >>>> If such function doesn't exist, this is fine, then could find that >>>> node manually by calculating from treesit-parser-included-ranges. >>> >>> Maybe we need two new primitives: >>> >>> (treesit-next-parser-boundary POS) >>> (treesit-prev-parser-boundary POS) >> >> Now pushed as 'treesit-closest-parser-boundary'. > > Hold on, let’s not get ahead of ourselves. First of all, the name is not > very descriptive IMO it actually finds range boundary, not parser boundary; > and the docstring mentions local parser while the function itself doesn’t > really involve local parsers—it just checks parser ranges. It can be used > for getting out of local parsers, yes, but that’s a use-case, not what it > does. So if we want to add this function to the public API set for > tree-sitter, it needs a better docstring. (And at the moment I have doubt > on its general usefulness.) I assumed that this function will not remain in the final implementation of this feature. I added it temporarily to get the embedded outlines into a working state. > More over, is this even necessary? Why do we need to go over all the > ranges for all the parsers to get out of a local parser? I thought we > can just get the local parser and get it’s range? I tried to use treesit-local-parsers-at, but it always returns nil. >>> (treesit-upper-parser-node POS) >> >> Addition of 'treesit-upper-parser-node' is underway that should >> be used in 'treesit-up-list' as well. > > And if we need to get the “parent node” of a local parser, we can do it in > much nicer ways. We can record the parent node when creating the local > parser, by either adding a field to the parser object, or record it in > a local database, or even just save it in the text property alongside the > local parser. Let’s take some time and think of the best way to solve > this. Now I improved treesit-outline-level as well without adding new functions. Everything works now, so we can do more refactoring without introducing regressions. > Whatever you have in mind, I suspect that it wouldn’t work if there > are more than one layer of nesting of parsers, ie, what if you want to get > out of a embedded (local) parser’s embedded parser? The current implementation in treesit-outline-level works with any depth of nested parsers. But the current solution is quite fragile. So we need to find a better way such as recording the parent parser node somewhere. > On the same note, we actually need some proper tree structure for the > primary parser - local parser relationship, because there can be more than > one layer. What we currently have doesn’t handle this well (font-lock and > indentation). It’s a real use case, someone requested for this for the Perl > (or Haskell?) mode, and imagine a rust buffer embeds a markdown comment > which embeds rust code examples. I bring this up because this tree > structure would’ve solved your problem here as well, once we have it. Agreed, this needs a better design.
bug-gnu-emacs@HIDDEN:bug#76398; Package emacs.
Full text available.Received: (at 76398) by debbugs.gnu.org; 22 Feb 2025 06:13:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 22 01:13:23 2025 Received: from localhost ([127.0.0.1]:44522 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tlilO-0007my-Qv for submit <at> debbugs.gnu.org; Sat, 22 Feb 2025 01:13:23 -0500 Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]:52630) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <casouri@HIDDEN>) id 1tlilK-0007lf-NA for 76398 <at> debbugs.gnu.org; Sat, 22 Feb 2025 01:13:20 -0500 Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-2fc291f7ddbso4656170a91.1 for <76398 <at> debbugs.gnu.org>; Fri, 21 Feb 2025 22:13:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740204792; x=1740809592; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=UgSPHkZyxRfpk+vHTcgFAThBYLKp7Lzfm3E/Oaa+GGU=; b=mePMqRXPj8IB+gPJag/+yRtcKDpxvxoFAQ5kBZT6aT/bUxA734onffY8LXIsN1IW/x DKTLiTQUtJfATWkpVwwQbwW2Hoe6QAUBOrdCDOyiC2BVq/OhWvk7qqF9/IwUzuXv6bTI KrnEo/9XIay8kTWn0E6mT/0YVLTEHvWSHT/3miA+TLXyaiF3we6oqIufP0TgXu4Q7VCc Gsdq6CXW/MQqQ3Hih90lR4sX5X6GtSxYKDPUbXrtmA4QJtQBGylkDvUorBo27GxaWkza Xp7tIVIjuyLLSrzMbtU/gwG2HmKIx1jQCPg4nA0yAWCpB3krfqNjh/8Ogpe9XAcbojUr r4rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740204792; x=1740809592; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=UgSPHkZyxRfpk+vHTcgFAThBYLKp7Lzfm3E/Oaa+GGU=; b=RsM/NYNCfeex+hycdsBrqrG9UiX0ZGRIA0Ku6EJ9Pjh8zSXrowkhqB6eAYNjYdOZQG g4/uE0GiX2vFSGaROH7jcIIXWDM1ZU3xlFtY7Dy9iwo4ZjwUCGn8i1bHW8O0EJpSFnFL VM907kAM4Ax9u39frmzRPRtGKRAryVHCaB6eD+g06ewHN2oHpr/a1ECFGMST3IlZAlMC AIl73tUkHRfXWXlEYVXogClpikFED6oGD6AkIYybH9kHZYocLydUGNLkpNTHzAgPFd3h 2juZgxwIc+EhwKV1M1wBIcCEshz5BMAQZ8jgFXUIP/aKD5z86S76bCJPuEFH6EIX9DMh ofyw== X-Gm-Message-State: AOJu0YxRKiMg7xX+Bdmryt0s/P5QwohKLxsNBwu07JupV01G9y+oYdTq TyoNY9/7fNDSjcakl6tn/dTh286x538E0pOYlNKbnmO1Y9m2biXt X-Gm-Gg: ASbGncsLbJVLi6fKtzxgF7C2qRVeOWbyza8OMeg14dvDR70jW4rxqiAEqP8s9flfQgq N9GBprIzwleb/nvgNM8c6ltUMZtY1zGH+yJZJXO6qwDVvemr16816eK8uSud1Z0eVp61ig8wK+W iiNBh9zYl+LC/sU9s7LtlD+vjes6ylRnEYLObhULLvaS2uSjzexhfMK2LU2XWdIDMok3GwbQ0Jf XnrROxMMYQj/N7fHJoNzLc4xM4iHWnHI2qbgy8nIb4E8x2V6NZxc+EMFXV5COgMOufsBaWwdLbA E3TVIhVUZTNkazXVZUq7mmChEfdl7V0d+aOnK2sfgNtP42zzzg== X-Google-Smtp-Source: AGHT+IG2OZTDHQskdZklt7mAz2JCY9gU9D42qZehIvSg0GI+kr52HN/Xl2aQrCH+doOHnuJWvPnYZQ== X-Received: by 2002:a05:6a00:17a2:b0:732:5935:c219 with SMTP id d2e1a72fcca58-73426c8dcb1mr10518802b3a.3.1740204792144; Fri, 21 Feb 2025 22:13:12 -0800 (PST) Received: from smtpclient.apple ([2601:646:8f81:6120:9c39:a9fb:7754:17f8]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7325b1afd0esm14353542b3a.137.2025.02.21.22.13.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Feb 2025 22:13:11 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: bug#76398: treesit-aggregated-outline-predicate From: Yuan Fu <casouri@HIDDEN> In-Reply-To: <87tt8nohnp.fsf@HIDDEN> Date: Fri, 21 Feb 2025 22:12:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7D07FD47-D2E2-4972-9A0F-0DDF8431C2E2@HIDDEN> References: <87tt8rrwnf.fsf@HIDDEN> <87frkas7g0.fsf@HIDDEN> <87tt8nohnp.fsf@HIDDEN> To: Juri Linkov <juri@HIDDEN> X-Mailer: Apple Mail (2.3776.700.51) X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 76398 Cc: 76398 <at> debbugs.gnu.org, v.pupillo@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.3 (/) > On Feb 20, 2025, at 11:56=E2=80=AFPM, Juri Linkov <juri@HIDDEN> = wrote: >=20 >>> So this patch helps 'treesit-outline-search' to get out of the local = parser >>> to the primary parser to continue search for the next outline = predicate. >>>=20 >>> 'treesit-outline-level' should do the same, but currently I can't = find >>> a suitable function to break out of embedded confinement >>> and get the host node that contains the guest ranges. >>> I mean that e.g. (treesit-parser-root-node (treesit-node-parser = node)) >>> can get the root node of the local parser, but how to get its parent = node >>> in the primary parser? It's understandable that treesit-node-parent >>> doesn't go out of its parser. But maybe there is another function? >>> If such function doesn't exist, this is fine, then could find that >>> node manually by calculating from treesit-parser-included-ranges. >>=20 >> Maybe we need two new primitives: >>=20 >> (treesit-next-parser-boundary POS) >> (treesit-prev-parser-boundary POS) >=20 > Now pushed as 'treesit-closest-parser-boundary'. Hold on, let=E2=80=99s not get ahead of ourselves. First of all, the = name is not very descriptive IMO it actually finds range boundary, not = parser boundary; and the docstring mentions local parser while the = function itself doesn=E2=80=99t really involve local parsers=E2=80=94it = just checks parser ranges. It can be used for getting out of local = parsers, yes, but that=E2=80=99s a use-case, not what it does. So if we = want to add this function to the public API set for tree-sitter, it = needs a better docstring. (And at the moment I have doubt on its general = usefulness.) More over, is this even necessary? Why do we need to go over all the = ranges for all the parsers to get out of a local parser? I thought we = can just get the local parser and get it=E2=80=99s range? >> (treesit-upper-parser-node POS) >=20 > Addition of 'treesit-upper-parser-node' is underway that should > be used in 'treesit-up-list' as well. And if we need to get the =E2=80=9Cparent node=E2=80=9D of a local = parser, we can do it in much nicer ways. We can record the parent node = when creating the local parser, by either adding a field to the parser = object, or record it in a local database, or even just save it in the = text property alongside the local parser. Let=E2=80=99s take some time = and think of the best way to solve this. Whatever you have in mind, I = suspect that it wouldn=E2=80=99t work if there are more than one layer = of nesting of parsers, ie, what if you want to get out of a embedded = (local) parser=E2=80=99s embedded parser? On the same note, we actually need some proper tree structure for the = primary parser - local parser relationship, because there can be more = than one layer. What we currently have doesn=E2=80=99t handle this well = (font-lock and indentation). It=E2=80=99s a real use case, someone = requested for this for the Perl (or Haskell?) mode, and imagine a rust = buffer embeds a markdown comment which embeds rust code examples. I = bring this up because this tree structure would=E2=80=99ve solved your = problem here as well, once we have it. Yuan=
bug-gnu-emacs@HIDDEN:bug#76398; Package emacs.
Full text available.Received: (at 76398) by debbugs.gnu.org; 21 Feb 2025 08:08:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 21 03:08:05 2025 Received: from localhost ([127.0.0.1]:52072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tlO4q-0007Bn-Sy for submit <at> debbugs.gnu.org; Fri, 21 Feb 2025 03:08:05 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51620) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tlO4o-0007AE-My for 76398 <at> debbugs.gnu.org; Fri, 21 Feb 2025 03:08:03 -0500 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 <eliz@HIDDEN>) id 1tlO4j-0005mQ-7C; Fri, 21 Feb 2025 03:07:57 -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=ypXzr1Ax/ykKaluLfSa8pj+KllPvlMnrNWDW7HMgo1o=; b=f6Uh2MA53ioq iv/B+dj5NAXPR/KPoddzBmkZN+zQagte7L6uGPJxI4z2JK6I/R2JyXDBfB5sNjcZkYf/if4JSHMfz x5ykKdOw58MKdrdZ5yuNaTMl3xxgrCDsDg8lZKGUXIH55Co7HlJfrM1P3Finyj3Rs4WsHFejvmOb8 9VpARp+o4eFjswvD129tYJTnQfAArRxf9JIpZuIlqs5OftfXcHXlIxqhMAkmp3mC3RI08PZ0Zi0jc pacoh0IRZx4Enh2hBBfn/UAtBSU7JHg/QsVm+/TANv9GEcNJ+/CXSdyLljmmi/M49N1R4Gxrh6eoi MGvXq8j0pBMNE8QlXWhXLw==; Date: Fri, 21 Feb 2025 10:07:54 +0200 Message-Id: <86seo72011.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Juri Linkov <juri@HIDDEN> In-Reply-To: <87tt8nohnp.fsf@HIDDEN> (message from Juri Linkov on Fri, 21 Feb 2025 09:56:10 +0200) Subject: Re: bug#76398: treesit-aggregated-outline-predicate References: <87tt8rrwnf.fsf@HIDDEN> <87frkas7g0.fsf@HIDDEN> <87tt8nohnp.fsf@HIDDEN> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 76398 Cc: 76398 <at> debbugs.gnu.org, v.pupillo@HIDDEN, casouri@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.6 (--) > Cc: casouri@HIDDEN, v.pupillo@HIDDEN > From: Juri Linkov <juri@HIDDEN> > Date: Fri, 21 Feb 2025 09:56:10 +0200 > > > Maybe we need two new primitives: > > > > (treesit-next-parser-boundary POS) > > (treesit-prev-parser-boundary POS) > > Now pushed as 'treesit-closest-parser-boundary'. Should it be documented in parsing.texi, together with other treesit functions? Thanks.
bug-gnu-emacs@HIDDEN:bug#76398; Package emacs.
Full text available.Received: (at 76398) by debbugs.gnu.org; 21 Feb 2025 07:57:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 21 02:57:35 2025 Received: from localhost ([127.0.0.1]:51918 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tlNuh-0005Z0-F2 for submit <at> debbugs.gnu.org; Fri, 21 Feb 2025 02:57:35 -0500 Received: from relay8-d.mail.gandi.net ([2001:4b98:dc4:8::228]:38757) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1tlNue-0005XY-Bh for 76398 <at> debbugs.gnu.org; Fri, 21 Feb 2025 02:57:33 -0500 Received: by mail.gandi.net (Postfix) with ESMTPSA id 46ADF44426; Fri, 21 Feb 2025 07:57:23 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: 76398 <at> debbugs.gnu.org Subject: Re: bug#76398: treesit-aggregated-outline-predicate In-Reply-To: <87frkas7g0.fsf@HIDDEN> Organization: LINKOV.NET References: <87tt8rrwnf.fsf@HIDDEN> <87frkas7g0.fsf@HIDDEN> Date: Fri, 21 Feb 2025 09:56:10 +0200 Message-ID: <87tt8nohnp.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-State: clean X-GND-Score: 0 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeileeglecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfitefpfffkpdcuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedtudenucenucfjughrpefhvfevufgjohhffffkfgggtgesthdtredttdertdenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucggtffrrghtthgvrhhnpeffgeetfeevlefhleejfeeuheeiudeitdffhfdutdekfeffgffhveehteegueekheenucfkphepledurdduvdelrdeliedrieeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepledurdduvdelrdeliedrieeipdhhvghlohepmhgrihhlrdhgrghnughirdhnvghtpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhgspghrtghpthhtohepfedprhgtphhtthhopehvrdhpuhhpihhllhhosehgmhgrihhlrdgtohhmpdhrtghpthhtoheptggrshhouhhrihesghhmrghilhdrtghomhdprhgtphhtthhopeejieefleekseguvggssghughhsrdhgnhhurdhorhhg X-GND-Sasl: juri@HIDDEN X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 76398 Cc: casouri@HIDDEN, v.pupillo@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) >> So this patch helps 'treesit-outline-search' to get out of the local parser >> to the primary parser to continue search for the next outline predicate. >> >> 'treesit-outline-level' should do the same, but currently I can't find >> a suitable function to break out of embedded confinement >> and get the host node that contains the guest ranges. >> I mean that e.g. (treesit-parser-root-node (treesit-node-parser node)) >> can get the root node of the local parser, but how to get its parent node >> in the primary parser? It's understandable that treesit-node-parent >> doesn't go out of its parser. But maybe there is another function? >> If such function doesn't exist, this is fine, then could find that >> node manually by calculating from treesit-parser-included-ranges. > > Maybe we need two new primitives: > > (treesit-next-parser-boundary POS) > (treesit-prev-parser-boundary POS) Now pushed as 'treesit-closest-parser-boundary'. > (treesit-upper-parser-node POS) Addition of 'treesit-upper-parser-node' is underway that should be used in 'treesit-up-list' as well.
bug-gnu-emacs@HIDDEN:bug#76398; Package emacs.
Full text available.Received: (at 76398) by debbugs.gnu.org; 19 Feb 2025 07:47:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 19 02:47:07 2025 Received: from localhost ([127.0.0.1]:41309 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tkenS-00007B-W9 for submit <at> debbugs.gnu.org; Wed, 19 Feb 2025 02:47:07 -0500 Received: from relay7-d.mail.gandi.net ([2001:4b98:dc4:8::227]:52679) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1tkenP-00005n-Tz for 76398 <at> debbugs.gnu.org; Wed, 19 Feb 2025 02:47:04 -0500 Received: by mail.gandi.net (Postfix) with ESMTPSA id 293EA441F0; Wed, 19 Feb 2025 07:46:53 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: 76398 <at> debbugs.gnu.org Subject: Re: bug#76398: treesit-aggregated-outline-predicate In-Reply-To: <87tt8rrwnf.fsf@HIDDEN> Organization: LINKOV.NET References: <87tt8rrwnf.fsf@HIDDEN> Date: Wed, 19 Feb 2025 09:46:23 +0200 Message-ID: <87frkas7g0.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-State: clean X-GND-Score: 0 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeifeeikecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfitefpfffkpdcuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedtudenucenucfjughrpefhvfevufgjohhffffkfgggtgesthdtredttdertdenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucggtffrrghtthgvrhhnpeffgeetfeevlefhleejfeeuheeiudeitdffhfdutdekfeffgffhveehteegueekheenucfkphepledurdduvdelrdelkedrheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeeluddruddvledrleekrdehpdhhvghlohepmhgrihhlrdhgrghnughirdhnvghtpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhgspghrtghpthhtohepfedprhgtphhtthhopehvrdhpuhhpihhllhhosehgmhgrihhlrdgtohhmpdhrtghpthhtoheptggrshhouhhrihesghhmrghilhdrtghomhdprhgtphhtthhopeejieefleekseguvggssghughhsrdhgnhhurdhorhhg X-GND-Sasl: juri@HIDDEN X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 76398 Cc: casouri@HIDDEN, v.pupillo@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > So this patch helps 'treesit-outline-search' to get out of the local parser > to the primary parser to continue search for the next outline predicate. > > 'treesit-outline-level' should do the same, but currently I can't find > a suitable function to break out of embedded confinement > and get the host node that contains the guest ranges. > I mean that e.g. (treesit-parser-root-node (treesit-node-parser node)) > can get the root node of the local parser, but how to get its parent node > in the primary parser? It's understandable that treesit-node-parent > doesn't go out of its parser. But maybe there is another function? > If such function doesn't exist, this is fine, then could find that > node manually by calculating from treesit-parser-included-ranges. Maybe we need two new primitives: (treesit-next-parser-boundary POS) (treesit-prev-parser-boundary POS) and (treesit-upper-parser-node POS)
bug-gnu-emacs@HIDDEN:bug#76398; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 18 Feb 2025 17:35:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 18 12:35:13 2025
Received: from localhost ([127.0.0.1]:60578 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tkRV2-0002Yk-FR
for submit <at> debbugs.gnu.org; Tue, 18 Feb 2025 12:35:13 -0500
Received: from lists.gnu.org ([2001:470:142::17]:44942)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1tkRV0-0002T0-PA
for submit <at> debbugs.gnu.org; Tue, 18 Feb 2025 12:35:11 -0500
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 <juri@HIDDEN>) id 1tkRUu-0001CB-QE
for bug-gnu-emacs@HIDDEN; Tue, 18 Feb 2025 12:35:05 -0500
Received: from relay2-d.mail.gandi.net ([217.70.183.194])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <juri@HIDDEN>) id 1tkRUr-0001zy-QF
for bug-gnu-emacs@HIDDEN; Tue, 18 Feb 2025 12:35:04 -0500
Received: by mail.gandi.net (Postfix) with ESMTPSA id C8BAB4418D
for <bug-gnu-emacs@HIDDEN>; Tue, 18 Feb 2025 17:34:56 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: treesit-aggregated-outline-predicate
Organization: LINKOV.NET
X-Debbugs-Cc: casouri@HIDDEN, v.pupillo@HIDDEN
Date: Tue, 18 Feb 2025 19:27:17 +0200
Message-ID: <87tt8rrwnf.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-GND-State: clean
X-GND-Score: 0
X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeiudelvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfitefpfffkpdcuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedtudenucenucfjughrpefhvffuohffkfgfgggtsehmtderredtredtnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecuggftrfgrthhtvghrnhepveetfeeiuefhtdeguedukefgjeejkedvvdevhfdvfedtieefkeevleeikefffedunecukfhppeeluddruddvledrleekrdehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepledurdduvdelrdelkedrhedphhgvlhhopehmrghilhdrghgrnhguihdrnhgvthdpmhgrihhlfhhrohhmpehjuhhriheslhhinhhkohhvrdhnvghtpdhnsggprhgtphhtthhopedupdhrtghpthhtohepsghughdqghhnuhdqvghmrggtshesghhnuhdrohhrgh
X-GND-Sasl: juri@HIDDEN
Received-SPF: pass client-ip=217.70.183.194; envelope-from=juri@HIDDEN;
helo=relay2-d.mail.gandi.net
X-Spam_score_int: -24
X-Spam_score: -2.5
X-Spam_bar: --
X-Spam_report: (-2.5 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7,
RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
TRACKER_ID=0.1 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.8 (/)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.2 (/)
--=-=-=
Content-Type: text/plain
As discussed in bug#74610, in multi-language modes
treesit-outline-predicate ends abruptly after the first embedded range
since it can't find more matches in its range, it can't go out back
to the primary parser.
So this patch helps 'treesit-outline-search' to get out of the local parser
to the primary parser to continue search for the next outline predicate.
'treesit-outline-level' should do the same, but currently I can't find
a suitable function to break out of embedded confinement
and get the host node that contains the guest ranges.
I mean that e.g. (treesit-parser-root-node (treesit-node-parser node))
can get the root node of the local parser, but how to get its parent node
in the primary parser? It's understandable that treesit-node-parent
doesn't go out of its parser. But maybe there is another function?
If such function doesn't exist, this is fine, then could find that
node manually by calculating from treesit-parser-included-ranges.
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline;
filename=treesit-aggregated-outline-predicate.patch
diff --git a/lisp/textmodes/mhtml-ts-mode.el b/lisp/textmodes/mhtml-ts-mode.el
index 83f8879f427..7a481599310 100644
--- a/lisp/textmodes/mhtml-ts-mode.el
+++ b/lisp/textmodes/mhtml-ts-mode.el
@@ -580,7 +580,10 @@ mhtml-ts-mode
(setq-local treesit-aggregated-simple-imenu-settings
mhtml-ts-mode--treesit-aggregated-simple-imenu-settings)
- ;; (setq-local treesit-outline-predicate nil)
+ (setq-local treesit-aggregated-outline-predicate
+ `((html . ,#'html-ts-mode--outline-predicate)
+ (javascript . "\\`function_declaration\\'")
+ (css . "\\`rule_set\\'")))
(treesit-major-mode-setup)
diff --git a/lisp/treesit.el b/lisp/treesit.el
index 30efd4d4599..ab9bfc33d3d 100644
--- a/lisp/treesit.el
+++ b/lisp/treesit.el
@@ -3601,6 +3601,16 @@ treesit-outline-predicate
is constructed from the value of `treesit-simple-imenu-settings'
when a major mode sets it.")
+(defvar-local treesit-aggregated-outline-predicate nil
+ "Settings that configure `treesit-outline-search' for multi-language modes.
+
+The value should be an alist of (LANG . SETTINGS), where LANG is a
+language symbol, and SETTINGS has the same form as
+`treesit-outline-predicate'.
+
+When both this variable and `treesit-outline-predicate' are non-nil,
+this variable takes priority.")
+
(defun treesit-outline-predicate--from-imenu (node)
;; Return an outline searching predicate created from Imenu.
;; Return the value suitable to set `treesit-outline-predicate'.
@@ -3618,7 +3628,10 @@ treesit-outline-predicate--from-imenu
(defun treesit-outline--at-point ()
"Return the outline heading node at the current line."
- (let* ((pred treesit-outline-predicate)
+ (let* ((pred (if treesit-aggregated-outline-predicate
+ (alist-get (treesit-language-at (point))
+ treesit-aggregated-outline-predicate)
+ treesit-outline-predicate))
(bol (pos-bol))
(eol (pos-eol))
(current (treesit-thing-at (point) pred))
@@ -3649,9 +3662,35 @@ treesit-outline-search
(if (eq (point) (pos-bol))
(if (bobp) (point) (1- (point)))
(pos-eol))))
+ (pred (if treesit-aggregated-outline-predicate
+ (alist-get (treesit-language-at pos)
+ treesit-aggregated-outline-predicate)
+ treesit-outline-predicate))
(found (or bob-pos
- (treesit-navigate-thing pos (if backward -1 1) 'beg
- treesit-outline-predicate))))
+ (treesit-navigate-thing pos (if backward -1 1) 'beg pred))))
+
+ ;; Handle multi-language modes
+ (when-let* ((ranges (mapcar #'treesit-parser-included-ranges
+ (treesit-parser-list)))
+ (ranges (delq nil (delete '((1 . 1)) ranges))))
+ (if found
+ nil
+ ;; Possibly was inside the local range, and when can't find
+ ;; more matches inside the local range then need to go out
+ (when-let* ((bounds (seq-filter
+ (lambda (p) (if backward (< p pos) (> p pos)))
+ (flatten-list
+ (mapcar (lambda (rr)
+ (mapcar (if backward #'car #'cdr) rr))
+ ranges))))
+ (closest (when bounds (if backward (seq-max bounds) (seq-min bounds)))))
+ (setq found (treesit-navigate-thing
+ closest (if backward -1 1) 'beg
+ (if treesit-aggregated-outline-predicate
+ (alist-get (treesit-language-at closest)
+ treesit-aggregated-outline-predicate)
+ treesit-outline-predicate))))))
+
(if found
(if (or (not bound) (if backward (>= found bound) (<= found bound)))
(progn
@@ -3667,10 +3706,25 @@ treesit-outline-search
(defun treesit-outline-level ()
"Return the depth of the current outline heading."
(let* ((node (treesit-outline--at-point))
- (level 1))
- (while (setq node (treesit-parent-until node treesit-outline-predicate))
+ (level 1)
+ (parser (when treesit-aggregated-outline-predicate
+ (treesit-node-parser node)))
+ (pred (if treesit-aggregated-outline-predicate
+ (alist-get (treesit-language-at (point))
+ treesit-aggregated-outline-predicate)
+ treesit-outline-predicate)))
+ (while (setq node (treesit-parent-until node pred))
(setq level (1+ level)))
- (if (zerop level) 1 level)))
+ (when-let* ((_ parser)
+ (host-lang (treesit-parser-language treesit-primary-parser))
+ (_ (not (eq (treesit-language-at (point)) host-lang)))
+ (host-pred (alist-get host-lang treesit-aggregated-outline-predicate)))
+ ;; Now need to break out of embedded confinement
+ ;; and get the host node that contains the guest ranges
+ (setq node (treesit-parser-root-node parser))
+ (while (setq node (treesit-parent-until node host-pred))
+ (setq level (1+ level))))
+ level))
;;; Hideshow mode
@@ -3955,11 +4009,14 @@ treesit-major-mode-setup
#'treesit-simple-imenu))
;; Outline minor mode.
- (when (and (or treesit-outline-predicate treesit-simple-imenu-settings)
+ (when (and (or treesit-outline-predicate
+ treesit-aggregated-outline-predicate
+ treesit-simple-imenu-settings)
(not (seq-some #'local-variable-p
'(outline-search-function
outline-regexp outline-level))))
- (unless treesit-outline-predicate
+ (unless (or treesit-outline-predicate
+ treesit-aggregated-outline-predicate)
(setq treesit-outline-predicate
#'treesit-outline-predicate--from-imenu))
(setq-local outline-search-function #'treesit-outline-search
--=-=-=--
Juri Linkov <juri@HIDDEN>:casouri@HIDDEN, v.pupillo@HIDDEN, bug-gnu-emacs@HIDDEN.
Full text available.casouri@HIDDEN, v.pupillo@HIDDEN, bug-gnu-emacs@HIDDEN:bug#76398; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.