From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.devel Subject: Re: Creating a paradigm for leveraging Tree Sitter's power Date: Sat, 24 Dec 2022 01:09:17 -0800 Message-ID: References: <948662B3-F284-4E89-BFE2-4BCB5007D4EA@easesoftware.com> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14951"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel To: Perry Smith Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 24 10:10:08 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p90Xf-0003hD-Rj for ged-emacs-devel@m.gmane-mx.org; Sat, 24 Dec 2022 10:10:07 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p90X2-00062B-Ew; Sat, 24 Dec 2022 04:09:28 -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 1p90X0-00061k-M3 for emacs-devel@gnu.org; Sat, 24 Dec 2022 04:09:26 -0500 Original-Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p90Wx-0007wm-L5 for emacs-devel@gnu.org; Sat, 24 Dec 2022 04:09:26 -0500 Original-Received: by mail-wr1-x42a.google.com with SMTP id y8so6402150wrl.13 for ; Sat, 24 Dec 2022 01:09:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; 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=q4Q5xfPpniY14zV9gVeHAz+VxszWztApYPgPUUiKHPs=; b=eTStj4WFvWFxPcIDinDUPJUUWDQ+nE7kml3W0MRIERAlmUOFSPuFU7jnaEhRnliDrz waFhUvzKY4uJpuyGRsoyZ/861oblba1k0aWwcvqqCGuBwWgMbpjMJln54DwE6eftrq4a r9A9QG3XxCQBz+SwDgyoDWBwDOoVPd1yrDMBBFoKOsClXR9y6thqhFi3sRJqmivxWIxh K+/75Pej2mZn3deIyXKY1aKC/RWEB5Dx2QIdCudO5+YX+c9sPTOCL76O195gv/dyIuwI p4mP+9S1iUf83dwGtn/G8gqYLaxaMmJxsf9NIhA+eQe9aOQZYCkc/nT/YHoo7cJ2M5uv d2IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=q4Q5xfPpniY14zV9gVeHAz+VxszWztApYPgPUUiKHPs=; b=6p62AUbVqM2A2fw9U8ugWL0L2v00MM8PiXX+p0VS2i8tN3ELdY5tkW+SwpCS8i+Q0Q eOaZpALoj3BIbOM2LTta94GtqASUCxA17kwEbYKB92lo9FoLxbbXx5xmUBMOYencwYwW 778oX4JZLf2j0sbYqzTSUzT7akRN/MddiuiSMivdOzgavT/pXHaLgbazSV8yK4zJGxox BAaXlOGymTWaHEaVQ1Xolr+Q1YN2niavRHLEib8EPO6WF/gSHQzrnvcTB35m9WBSvcTy oO+hH9NPwxUoYnxce5qfChjcWYEQHoHj0XsIaleXOqnFv2FtAu4I8aZkhD7T9tVbGctq sz5g== X-Gm-Message-State: AFqh2krMhSGFWjQB2c5IEhAp9wfInotqTvN7hobjYSbPNV7Tj+kAHiln 7/2YaEi4v6l0r8Tby1db2gbg8Urlz2Y= X-Google-Smtp-Source: AMrXdXsnCMX6R6+0/0YEtpRJOezjsWfP/VYoVYVpG2AL31nB+DsozQ4X6feAO9iOyjXVQxkRK0eRIA== X-Received: by 2002:adf:ce0a:0:b0:246:e6df:86e7 with SMTP id p10-20020adfce0a000000b00246e6df86e7mr7870596wrn.5.1671872961120; Sat, 24 Dec 2022 01:09:21 -0800 (PST) Original-Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id n12-20020a5d51cc000000b00241da0e018dsm5056746wrv.29.2022.12.24.01.09.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Dec 2022 01:09:20 -0800 (PST) In-Reply-To: <948662B3-F284-4E89-BFE2-4BCB5007D4EA@easesoftware.com> X-Mailer: Apple Mail (2.3696.120.41.1.1) Received-SPF: pass client-ip=2a00:1450:4864:20::42a; envelope-from=casouri@gmail.com; helo=mail-wr1-x42a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:301831 Archived-At: > On Dec 23, 2022, at 5:32 PM, Perry Smith = wrote: >=20 > I've seen on this list talk about "adding" Tree Sitter concepts to > such things as mark-defun and other existing Emacs commands. >=20 > I've just spent a few days writing rtsn-mark-method that I intend on > adding to ruby-ts-mode which implements all the features of mark-defun > but I did it from scratch. This is mostly out of ignorance on how to > leverage existing Emacs features and facilities. >=20 > One more concrete reason is mark-defun will include the comments > before the defun. I wanted the same for mark-method but (as far as I > can tell) the hooks back into mark-defun and its associated routines > are simple regular expressions and that, to me, walks away form the > power that Tree Sitter is providing. >=20 > I've got rtsn-mark-method working but I plan to rework it over the > next few days. The "arg" as well as the "interactive" features of > mark-defun which I also put into rtsn-mark-method I believe can be > pulled out to a wrapper routine. There is actually quite a few > features in the code that I did not know about. For example, if > mark-defun is called with -1 (or -N) it marks N back. Ok. But now if > it is called again with no argument, mark-defun knows to go backwards > to add in the previous defun. The same is true in the forward > direction as well. (Although it does have a subtle bug in my opinion > but I digress.) >=20 > To repeat myself, I believe these higher level features could be > separated into a wrapper function so that all that would be needed for > the language specific piece is a routine that would be passed a point > and a direction. I think it makes a lot of sense. >=20 > I'll call this the "primitive routine". The routine would be > responsible for returning a beginning and end (in a cons cell) and it > would be the routine's responsibility to make sure that the beginning > and end lie after (in the forward case) or before (in the backward > case) the point that is passed in. You mean beginning and end of (symbol | string | statement | =E2=80=A6)? =46rom my experience implementing defun navigation for tree-sitter, it = might be more helpful to return three ranges: the thing before point, = the thing at point, and the thing after point, and either one could be = nil if there doesn=E2=80=99t exist one. For nested things it can be = prev-sibling, parent, next-sibling instead. The point is that the user = can move back and forward and make decisions easily with this =E2=80=9Cfie= ld of view=E2=80=9D. >=20 > The wrapper routine would then know how to properly adjust the mark > and point, execute counts, add to regions, catch errors, etc. >=20 > Broadening the picture: navigation, transpose, and other Emacs > commands could likewise call the same primitive routine to provide > transpose-method, forward-method, etc. And, broadening the picture > once more: primitive routines could be written not just for methods > (defun) but also for statements, arguments, expressions, classes, etc. > In all cases, the primitive routine would be relatively simple. It > would be given a point and return a ( begin . end ) cons cell leaving > all the harder work of expanding the region, remembering the > direction, etc to the wrapper routines. >=20 > To be clear, there would be a wrapper routine for mark, a wrapper for > forward, transpose, etc. We would end up with the classic: >=20 > For A + B number of routines we would have A x B number of commands. >=20 > Does this strike others as a good idea or insanity? Yeah it sounds pretty good. Probably no one needs/wants all the A x B = combinations, but the framework that allows this miss and match is good, = since it allows us easily create the few combinations we care about. We = need more brains thinking about it and more experiments to fully flesh = it out. We also had a related discussion in another thread =E2=80=9CPlug = treesit.el into other emacs constructs=E2=80=9D. Yuan=