From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Theodor Thornhill Newsgroups: gmane.emacs.devel Subject: Re: Plug treesit.el into other emacs constructs Date: Wed, 14 Dec 2022 09:42:09 +0100 Message-ID: <87edt21in2.fsf@thornhill.no> References: <87wn6whete.fsf@thornhill.no> <87r0x3gnv5.fsf@thornhill.no> <04BB786A-3ED1-4918-8583-17AA01A1E453@gmail.com> <4E3940CA-67A6-45B7-8785-4E60FDECCDFB@gmail.com> Mime-Version: 1.0 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="30084"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, eliz@gnu.org To: Yuan Fu , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 14 09:45:54 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 1p5NOk-0007cK-0v for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Dec 2022 09:45:54 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p5NLF-0005Qm-5q; Wed, 14 Dec 2022 03:42:17 -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 1p5NLD-0005N1-84 for emacs-devel@gnu.org; Wed, 14 Dec 2022 03:42:15 -0500 Original-Received: from out-241.mta0.migadu.com ([91.218.175.241]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p5NLB-0007YM-8l for emacs-devel@gnu.org; Wed, 14 Dec 2022 03:42:14 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1671007331; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pEIrdvWa7gsD4l2W5MRLxnmGA+nGZuk7K9Ve7NuN/vA=; b=MZUKRu6K+64iGfEhGK9/b486HY59VhYKLUmBnCObD/0YCr4suDdvUNQN38D6mMaeFHGedJ GG+gMytmw6Ay6xNO12SdVCacPDBmO/lY4gJsXvbqcYwgVmJgNbNCP/ItON63pXmfM7ywXu uwCId3l4+LyAhfBnRlrp120aeYrem/7Vm45vVNScRkkhB0L4eT4oNXbgJpg3jYRec77ICX TDc1+arB1fO+2QLLSF3bojk0iTllbeU1XxiKrByCHrQdCWIRzEcC6sF3C4KbT1mgjIVD1i KFeR/Qk8zQB8VVxhnUgx5gc9e6mxWW7mGt79913ggxQkHesUE/mgUcQ+yc7kEQ== In-Reply-To: <4E3940CA-67A6-45B7-8785-4E60FDECCDFB@gmail.com> X-Migadu-Flow: FLOW_OUT Received-SPF: pass client-ip=91.218.175.241; envelope-from=theo@thornhill.no; helo=out-241.mta0.migadu.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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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:301373 Archived-At: Yuan Fu writes: >> On Dec 13, 2022, at 3:19 PM, Stefan Monnier w= rote: [...] >>=20 >>> Just a thought, but maybe we can let major modes define what=E2=80=99s = an =E2=80=9Cabstract >>> list=E2=80=9D, and sexp-forward would move across the immediate childre= n of abstract >>> lists. Eg, abstract lists in C would contain block, argument list, >>> statement, etc. And in the example above forward-sexp would move across >>> X.y(z) because it=E2=80=99s an immediate children of the enclosing abst= ract list, >>> the argument list. >>=20 >> Using the semantics I advocate, the user needs to place his point just >> to the left of `;` in order for `forward-sexp` to jump over the next >> instruction (or to the right of the `;` in order to jump over the >> previous instruction with `backward-sexp`). > > You mean in the following code > > int a =3D 0[1]; > int b =3D 1;[2] > > Forward-sexp would move [1] to [2]? But if we move over the smallest > subtree, I=E2=80=99d imagine it only move across the semicolon after [1].= Even > if it moves from [1] to [2], needing to adjust point feels very > inconvenient to me, at least I wouldn=E2=80=99t want to use something like > that. I want to type a single binding and move to where I want, and > type that binding multiple times to move multiple steps. Both doesn=E2=80= =99t > seem to be possible with what you described. > Yeah. My intuition for forward-sexp was always "some construct bigger than a 'word'". But in tree-sitter we also get the opportunity to make code stay valid. For example: void foo(String bar, int baz) | {} In this case it wouldn't make sense for transpose-sexps to do the following: void foo {} | (String bar, int baz) Because that wouldn't be valid java. But swapping the params inside would make sense, but only when the whole node is pulled over. And it point is directly between the paren opener and 'String', forward-sexp would make sense to jump to the comma, because forward-word would do the smaller movement. Theo