From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Plug treesit.el into other emacs constructs Date: Tue, 13 Dec 2022 14:37:32 -0500 Message-ID: References: <87wn6whete.fsf@thornhill.no> <87r0x3gnv5.fsf@thornhill.no> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9141"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org, eliz@gnu.org, casouri@gmail.com To: Theodor Thornhill Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 13 20:38:45 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 1p5B6z-00029G-0C for ged-emacs-devel@m.gmane-mx.org; Tue, 13 Dec 2022 20:38:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p5B5z-0005VF-H4; Tue, 13 Dec 2022 14:37:43 -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 1p5B5x-0005V0-34 for emacs-devel@gnu.org; Tue, 13 Dec 2022 14:37:41 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p5B5v-0000EV-7S; Tue, 13 Dec 2022 14:37:40 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C02EC442B1C; Tue, 13 Dec 2022 14:37:36 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 14B3F442B1A; Tue, 13 Dec 2022 14:37:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1670960255; bh=bsJRif1fHc6ONBLPkx1/Se/GvPp91cL2RB6Enx28v8c=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Y/ltfMpuB/E7VL/cuxjx8aJ9rFLd9JcQZzl1YH3ebBzBzmroL7qboy/yr2YbJtfi7 C5sqpIDKT5DX6aBkLV7+xbj1+vxEVA2SxEl3mtvkIrDk3uZOWcaQC3TIEqr7Fg2eV4 ZIBtZirEEuEYplVL1kLUAhB6WjetsLawfbhaPONbjjMEL+S/3Z0R6DbkzGAoK6yHUX iWfhI2pDuCdd80koMuAQjyGElqiJtcXTKl/LUfy1XJPu+zuNWVb5QKBjgFE5ChHhO+ wP+uItaAz05NPdKAJqao+24jxWx9f4MkUSdahLf+9mI8ERTus0O41DBxpC+qYMvy06 E2s4KeSffs2dg== Original-Received: from pastel (unknown [45.72.193.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B9214120409; Tue, 13 Dec 2022 14:37:34 -0500 (EST) In-Reply-To: <87r0x3gnv5.fsf@thornhill.no> (Theodor Thornhill's message of "Tue, 13 Dec 2022 19:27:58 +0100") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:301354 Archived-At: >>> ** Forward-sexp: >>> Executing C-M-f repeatedly will go from: >>> ``` >>> public void foo(|String bar, String baz) {} >>> ``` >>> to >>> ``` >>> public void foo(String bar|, String baz) {} >>> ``` >> >> That looks wrong. `String` is a valid AST node. Whether it gets a node >> in tree-sitter or not, I don't know, but here there are several "sexps" >> that start at point and I think `forward-sexp` should be conservative >> and keep advancing by the smallest option. > I understand. My reasoning is that 'forward-word' is suitable for that, It's not, tho, because it stops within identifiers like "foo_bar". There's a similar question for things like `String.match`. > and to actually gain something from these we need to use a little bigger > constructs. In tree-sitter 'String' isn't really valid, because you > need the identifier to create a complete node. I think we should not define the "ideal" behavior based on what Tree-sitter provides. As I said, in the *A*ST, `String` is a valid node. It's especially true if you consider more complex types like public void foo(Array, String>> bar, String baz) > In this case I'd think that forward-sexp would do: > ``` > x = |f (x) * 3 + 2; > x = f (x)| * 3 + 2; > x = f (x) * 3| + 2; > x = f (x) * 3 + 2;| > ``` > Or something like that. Similarly here I think it should first stop after `f`. The other ones look right to me. > So that multiple transpose-sexps would move > 'f(x)' over the operators, swapping with the integers. You could still do that, but you'd have to start with point next to `*` to specify the node whose children you want to swap. >>> ``` >>> public void foo(String bar, String baz|) {} >>> ``` >> >> That one's right :-) > > Why is this one right, and the above not? Because point was left of the comma and the smallest right child of the corresponding node is "String bar" and not "String" (which is more like the left child of the node that covers "String bar"). > Thanks for the feedback so far. I interpret this that this feature is > wanted, so I'll make a more serious effort and get back to you. Yes, definitely. It's one of the best features of SMIE compared to "hand-written" indentation code, if you ask me :-) Tree-sitter should be able to do it even better. > BTW, where are the semantics for these movement functions defined? In our heads. > I mean, what construct is each one expected to jump over? In my book "sexp" movement should jump over subtrees of the AST. Stefan