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: Wed, 14 Dec 2022 15:50:48 -0500 Message-ID: References: <87wn6whete.fsf@thornhill.no> <87r0x3gnv5.fsf@thornhill.no> <04BB786A-3ED1-4918-8583-17AA01A1E453@gmail.com> <4E3940CA-67A6-45B7-8785-4E60FDECCDFB@gmail.com> <4315EFC6-7AA8-4A48-845C-9CA8B88034D9@thornhill.no> <87bko521n0.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="7921"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Yuan Fu , emacs-devel@gnu.org, eliz@gnu.org To: Theodor Thornhill Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 14 21:51:38 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 1p5Yj4-0001oX-4u for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Dec 2022 21:51:38 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p5YiY-0006WB-KC; Wed, 14 Dec 2022 15:51:09 -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 1p5YiO-0006Vt-FK for emacs-devel@gnu.org; Wed, 14 Dec 2022 15:50:56 -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 1p5YiL-0001iT-NB; Wed, 14 Dec 2022 15:50:56 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9C841100563; Wed, 14 Dec 2022 15:50:51 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C6A741004AD; Wed, 14 Dec 2022 15:50:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1671051049; bh=F3ax0z+2O2HRc0XF/TzRj9kMmfoI0PV6PdCor/odEkc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=bkGeqwP2oRWBFBH8DVsgUS68CPvQl75jqtmljAl8bthxNxmyRMU6i4fROrl3jvxyn iN0bIrUQoPdT8wK3x9tCQNyckG6EARVtd1asMh61dHYtidX6v9rGP4PJPr0o5NsDOH ZhAZpM9v5qIb5vWx8UhBW8WlOOh+Z9gHXfuGhH8KNUphWJz7xw+jtwfkhxQiDShoGD 1C9M5ann+74yrQ26niABr6pcTgOYRbyUEyRiyoPXcV389zrZR0+LVm6V7/6nSovLIA PlY8uRxc8zIn+KtdDLZ0sgwV/z9WWjKFPZ3ENMKYAqvsKaZp6rFjIH4ALTC6tglMaW 8oKBh0P2+I2eA== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B62E61202C3; Wed, 14 Dec 2022 15:50:49 -0500 (EST) In-Reply-To: <87bko521n0.fsf@thornhill.no> (Theodor Thornhill's message of "Wed, 14 Dec 2022 21:04:03 +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:301412 Archived-At: >>>>In this case, yes. But in other cases it will move at different levels >>>>of the tree. E.g.: >>>> >>>> int x = f (b + 4, c * 7 - z * 2, d, e); >>>> >>>>It will sometimes move over the whole instruction, and other times over >>>>just a single variable or over a whole argument or over just a "factor". >>>>This depends on where point is when `forward/backward-sexp` is called. >>> >>> Yeah. I think this example shows what I find unintuitive. If point is right >>> before the first comma, and we transpose-sexps, it could end up swapping >>> 4 for c * 7 - z * 2, which would rarely make sense in this context. >> >> If so, that would be a bug in `transpose-sexp`, agreed. >> I'm talking here about `forward/backward-sexp`. >> The two are linked, but we shouldn't use one to justify a bug in the other. > > Sure, but I think they necessarily needs to be viewed as a whole. If we > drop tree-sitter or SMIE (which I actually know pretty well) for one > moment, the cc-mode based java-mode would exhibit the exact behavior I > described. Really? When I try it out in CC-mode's java-mode, I get from int x = f (b + 4|, c * 7 - z * 2, d, e); to int x = f (b + c, 4| * 7 - z * 2, d, e); which is not completely non-sensical, but is somewhere between a bug and a misfeature. > If it's a bug in tranpsose-sexps it is definitely an issue > with forward/backward-sexp, because in every situation the positions to > be swapped is just "backward-sexp - forward-sexp - forward-sexp - > backward-sexp", right? The way I see it, the problem with sexp movement and infix syntax is that a given buffer position maps to several positions at different levels in the AST (contrary to Lisp style syntax where there is no such ambiguity). So for every command, we need to decide/guess at which level of the AST the user wants to operate. For `transpose-sexp` we have more information than for `forward/backward-sexp` because some of those positions are "non-sensical" in the sense that they would end up swapping subtrees that live at different levels or that do not share their immediate parent. For this reason, what we should do with `transpose-sexp` is not necessarily exactly the same as what we should do with `backward/forward-sexp`. > And the thing in the middle, usually a comma, > operators or other is the space between that doesn't move. I also > observe this fixme inside of transpose-words: > > ;; FIXME: `foo a!nd bar' should transpose into `bar and foo'. > > I read this more like it's how transpose-sexps should behave on text. IIRC I wrote this when I was working on the SMIE `transpose-sexp` code :-) > Wouldn't it make sense to make transpose-sexps actually do what that > fixme asks? I obviously agree, since I wrote that fixme. > And why is the > > (cons (progn (funcall mover x) (point)) > (progn (funcall mover (- x)) (point))) > > in this form, and not some pseudo-code like: > (cons '(backward-thing-from-start-point forward-thing-point) > '(forward-thing-from-start-point backward-thing-point)) Sorry, haven't looked at the code in a while. Not sure what you're getting at here. I suspect that in the case of tree-sitter you'd ideally want to implement `transpose-sexp` directly rather than via something like `forward/backward-sexp`: - Go from point to a node in the tree. - Find the node whose children we want to swap. - Find the bounds of those two children. - Do the actual textual swap. > Now I'm having issues where movement over sexps ends up not in the > same place. Same place as? Stefan