From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mickey Petersen Newsgroups: gmane.emacs.bugs Subject: bug#60655: 30.0.50; tree-sitter: `treesit-transpose-sexps' is broken. Date: Mon, 09 Jan 2023 12:30:11 +0000 Organization: Mastering Emacs Message-ID: <877cxvj2ou.fsf@masteringemacs.org> References: <87r0w5jo0i.fsf@masteringemacs.org> <87sfgkgqlj.fsf@thornhill.no> <878ricjdee.fsf@masteringemacs.org> <87cz7nuc13.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="5998"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e @VERSION@; emacs 30.0.50 Cc: 60655@debbugs.gnu.org To: Theodor Thornhill Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 09 14:17:08 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1pEs1T-0001Kz-Ax for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 09 Jan 2023 14:17:07 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pErYU-00053m-7c; Mon, 09 Jan 2023 07:47:10 -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 1pErYM-000511-Tz for bug-gnu-emacs@gnu.org; Mon, 09 Jan 2023 07:47:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pErYM-0005cp-Le for bug-gnu-emacs@gnu.org; Mon, 09 Jan 2023 07:47:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pErYM-00006p-HF for bug-gnu-emacs@gnu.org; Mon, 09 Jan 2023 07:47:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Mickey Petersen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 09 Jan 2023 12:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60655 X-GNU-PR-Package: emacs Original-Received: via spool by 60655-submit@debbugs.gnu.org id=B60655.1673268400377 (code B ref 60655); Mon, 09 Jan 2023 12:47:02 +0000 Original-Received: (at 60655) by debbugs.gnu.org; 9 Jan 2023 12:46:40 +0000 Original-Received: from localhost ([127.0.0.1]:35996 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pErXz-000060-G8 for submit@debbugs.gnu.org; Mon, 09 Jan 2023 07:46:40 -0500 Original-Received: from mail-lo2gbr01on2097.outbound.protection.outlook.com ([40.107.10.97]:14800 helo=GBR01-LO2-obe.outbound.protection.outlook.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pErXw-00005k-Dq for 60655@debbugs.gnu.org; Mon, 09 Jan 2023 07:46:37 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R32ETjzjlHmKkDRflS3fb+TgF5QBxGOsjykAA+shyARWh4S/AXC2RSvh8Dl7Ew2d1wMi6LRd+kqxzsmeNkiIuDTQxQS3Xyes2jyYw3XWIe8a9b97TeFDiNRHBm8Pp6mi7NONh9dCmW8Z97h73YNp5/vTXRdM4JpO81r/wQC8o9v/bnaCnTvUidGhUTIrv3a8Z2asCN/u+Eq62vZenm2f3HtVpEvSZexvElMMo4ek+D1uqnSqMAiD6uAj6B28zifwOO37+lQYA+0MoCsHCqRtCWfQZcdCFM6WhzslSLXIH2KR9WB+fh6GwuP115tz1u2swXa82ytDT4TkGmjCoS/PNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/oJM6Jpn1jKkf4WzbEvPzktUJii07NjORHf+/Em9hns=; b=HPhzs4PsvB2oBReqgeUBfYWcUqr5YKhDFFt4GsjgjnnuX+4eurvn3iu+oL8pC9brfji68VliufqpfrTtSl3TNNixnaoXSQu6507A3QLaXqMveRswtK582bJRsMhy3/VSwNIgMv7QZ67VFIa/05YjvGYujvRlbTjUvgfPYGVjoHmWPBkm0BEZq887JYaF41KfvTRs8M8zOBGH9IbsWVCzhHUhWfdGvXdS+lk3tUMuUJBxVLJVAjSAcSIHbBoJM46XmLlXgcUzksaHXufJwJQVBavxu3O3MRYagM/ZL8bdfZ0wyMrDXTsBqi8/QuMyDHPBhEAXqdYTajEad/qi9k3LwQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 178.79.136.144) smtp.rcpttodomain=debbugs.gnu.org smtp.mailfrom=masteringemacs.org; dmarc=pass (p=none sp=none pct=100) action=none header.from=masteringemacs.org; dkim=pass (signature was verified) header.d=masteringemacs.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semantical.onmicrosoft.com; s=selector1-semantical-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/oJM6Jpn1jKkf4WzbEvPzktUJii07NjORHf+/Em9hns=; b=Db6qpYMT9RrPLpmmNf5bH/30NTdG0CkdCVY1OGzhDGaVUMKqlPW53caLpuY3CtoOolEf4IQZw3sMfLGwH6ob4GGUXLvzeFUNOo3QJBNSsawqHrzGmHfj+dqNuZlykgWKKUyGcLa/rLBGIXBr+6Id+sRBL69EWTwVMJ3/TOttdak= Original-Received: from LO2P265CA0246.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8a::18) by LO2P265MB5887.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:26c::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5986.18; Mon, 9 Jan 2023 12:46:29 +0000 Original-Received: from CWLGBR01FT007.eop-gbr01.prod.protection.outlook.com (2603:10a6:600:8a:cafe::10) by LO2P265CA0246.outlook.office365.com (2603:10a6:600:8a::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5986.18 via Frontend Transport; Mon, 9 Jan 2023 12:46:28 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 178.79.136.144) smtp.mailfrom=masteringemacs.org; dkim=pass (signature was verified) header.d=masteringemacs.org;dmarc=pass action=none header.from=masteringemacs.org; Received-SPF: Pass (protection.outlook.com: domain of masteringemacs.org designates 178.79.136.144 as permitted sender) receiver=protection.outlook.com; client-ip=178.79.136.144; helo=semantical.co.uk; pr=C Original-Received: from semantical.co.uk (178.79.136.144) by CWLGBR01FT007.mail.protection.outlook.com (10.152.40.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5986.18 via Frontend Transport; Mon, 9 Jan 2023 12:46:28 +0000 Original-Received: by semantical.co.uk (Postfix, from userid 5001) id 3E509114002; Mon, 9 Jan 2023 12:46:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=masteringemacs.org; s=masteringemacs.org; t=1673268388; bh=6FIu6yC+zpj71QrDgPyr+fur3/jCZvXuMF//nn8kk8k=; h=References:From:To:Cc:Subject:Date:In-reply-to:From; b=dNwUcFI5fYDwLo+vFBhiavLKEEOQyWdD+RP+0Yn8tdLEy4xbQmW6fKJxRHHd/DyZM r5npKI9vpjv5QVT2jJey8knezZAmNO/36P6P4CEndRxzLjQN52bxo1rnsURNt1IlIs 7E2WrPOhsQ9+NfrwuxOyrcnhJWVPUtOmcWO+K+Nw= In-reply-to: <87cz7nuc13.fsf@thornhill.no> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CWLGBR01FT007:EE_|LO2P265MB5887:EE_ X-MS-Office365-Filtering-Correlation-Id: 9c93476c-7bb4-4045-46ed-08daf23f86e2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: N8qk12qgi8Ofpacdyc/aKnMU/e/nFFayUiuC9993DsbTEQtN6+wDdDHz+pxHIVxNPBAlbSJt4omFVlMjdTED082Eb3OEWKNbwcU3KTuOdamHaZT+NJ5ccMnjg5kqVGSteqM5JkWh9qnrprA9Ncjkpt+nr7Fwf3r5LmLr73ztYg05FTwoXJIVPvbfw51uJCV/CiS9xV1fKdWT1Z6rkNKYEWUHchtMb/IOFd9wJRg9t5uVesK56QE+rYgoZE1/fMMBY/iiybWhd9QLD3Mc7Kcjhrr9tpfmyNSRjfhOIY6EKFetvptxis3cSspDJUzcOe65gEOd0U99jYshdshilxXoQD5J7ZdY7Me6ubvLd3TeThrEBSSEhS3/TWlbkyjTV6XauEj0LT9skA+qhmam9kZysomqy07VJtH9MCq+AkvVtEa0XxKpDqfi/3yKZf+A6Oc6lhWXk63UPENc9rWFW0peFYvwk8lSDsEBEaRwsE7eoD3L8U9d6iVsR/E04WOM2+x9+EObUvOE7t34z6DFnrmZP+T2NbQKDhin/3z6AOYuTeZtogAfU+M41o0F03yKRJkANuxXUhhVziOJV4rTi0+XBzSX7hnTPGplNd3U3YGEJJ0DbGvgdhxteSFVgBQ5iRtwVPhaesaIVkYuTCbXTDLnSZUcepHt4jug+p4okJSjhYTf2FBAqlVzbo0OI49BQghszz1nzlN2QN3eZt26V6/WB92mn9zo3oX2gBRKOzAto0EKSVF7CsK0bMzs5hkGU kf59O22wdXRkxKwkZ9ZXIwGoQ== X-Forefront-Antispam-Report: CIP:178.79.136.144; CTRY:GB; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:semantical.co.uk; PTR:semantical.co.uk; CAT:NONE; SFS:(13230022)(376002)(39830400003)(136003)(396003)(346002)(451199015)(36840700001)(46966006)(4326008)(42186006)(70586007)(70206006)(316002)(8676002)(36916002)(356005)(2906002)(7636003)(5660300002)(8936002)(7596003)(41300700001)(47076005)(6862004)(86362001)(36860700001)(478600001)(83380400001)(6666004)(336012)(6266002)(186003)(26005)(2616005)(40480700001)(36756003)(82310400005)(38230200001)(81973001)(79816003)(14776008); DIR:OUT; SFP:1102; X-OriginatorOrg: masteringemacs.org X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2023 12:46:28.5715 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9c93476c-7bb4-4045-46ed-08daf23f86e2 X-MS-Exchange-CrossTenant-Id: a4e27e3d-bab0-45e8-8942-e64cf9fbd34f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=a4e27e3d-bab0-45e8-8942-e64cf9fbd34f; Ip=[178.79.136.144]; Helo=[semantical.co.uk] X-MS-Exchange-CrossTenant-AuthSource: CWLGBR01FT007.eop-gbr01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB5887 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:253017 Archived-At: Theodor Thornhill writes: > Mickey Petersen writes: > >> Theodor Thornhill writes: >> >>> Mickey Petersen > The tree-sitter-enabled >>> function, `treesit-transpose-sexps', that is called by >>> transpose-sexps, is broken. >>>> >>>> It uses a naive method of sibling adjacency to determine >>>> transpositions. But it is unfortunately not correct. >>>> >>>> Python: >>>> >>>> >>>> def -!-foo(): >>>> pass >>>> >>>> Turns into this with `C-M-t': >>>> >>>> def ()foo: >>>> pass >>>> >>>> But it ought to be: >>>> >>>> foo def(): >>>> pass >>>> >>>> >>>> It's swapping two siblings that are indeed adjacent in the tree, but >>>> not on screen, which is confusing and a regression from its previous >>>> behaviour. >>>> >>> >>> I can try to make transpose-sexps rely on only swapping "allowed" >>> node-types? That would be able to keep the new, better function, yet >>> still disallow these syntax-breaking transposes. What do you think? >>> >> >> This is a hard problem. I'm building the self-same in Combobulate, so >> when I saw this implementation I saw a well-trodden path by myself. >> There's a lot of subtlety to it, and it is not immediately possible to >> accurately gauge the right things to swap with simple (or not so >> simple) sibling transpositions. >> >> Using a defined list is better, but with the caveat that it requires manual >> intervention per mode. This is a really tricky thing to build well. > > Yeah, but I guess that is a sensible change. It isn't easy, no, so I'm > open for suggestions and improvements. IMO an improvement would be to > increase the likelihood that a transpose-sexps will still be valid code. > I don't really think it is useful to do things like "def foo() -> foo > def()" because that is nonsensical code, and is covered by > transpose-words anyway. To me a _more_ sensible approach here would be > to transpose the defun at point with the next one, as they are usually > interchangeable. I am looking into such an improvement, and have been > for a while. > That, in my opinion, is the wrong way to look at it. `C-M-t' already works well: it transposes stuff around point. Nothing more, nothing less. If I write rubbish code as a human, no amount of machine intelligence will (yet) undo that. Nor should a 'clever' mechanism that is only clever by half. Trying to transpose things on, near or around point is a useful addition if, and only if, it can do so in a manner that is sensible, and predictable, to its operator. You will very quickly run into umpteen problems generalizing this. That's why I have shown restraint and limited Combobulate to things that I feel are simple (but made it quite easy for someone to customize, if they disagree!) As a user, I may well want to put my code into an erroneous state, temporarily, because I am doing something that cannot be represented atomically as a single command. Therefore, `self-insert-command' (for example) does not predict what I am about to type and intercedes when it disagrees with me: it merely abides. When I do this with `C-M-t' it is because it is an intentional act on my behalf. The example I gave above is illustrative; it's designed to highlight the problem. >> >> >> >>>> You could make a cogent argument that both approaches are wrong from a >>>> syntactic perspective, but I think that misses the broader point that >>>> `C-M-t' now does something errant and unexpected. >>> >>> I don't really see how "foo def():" is any better at all. We gain some >>> great improvements with this "naive" method - namely: >>> >>> if 5 + 5 == 10 then 10 else 100 + 100. If point is on the else the 100 >>> + 100 wil be swapped by 10, but the old behavior will be broken. >>> >> >> The old behaviour was consistent. It had a simple *modus operandi*: >> swap two things around point. As someone who has used `C-M-t' for >> decades, I know what it'll do in pretty much all situations, because I >> know what `C-M-k` and `C-M-f/b` do at all times. > > It may be consistent, but imo it is too close to transpose-words, and > too likely to create useless code in non-lisp languages. > No, transpose word and transpose sexp are very different; do different things; and apply in vastly different circumstances: Let -!- be point: d = {'Hello, World!': -!- 1} # C-M-t d = {1: 'Hello, World!'} # M-t d = {'Hello, 1!': World} `transpose-sexps' works just fine the way it is: enriching it with a greater understanding of certain contexts is a fruitful endeavour, if it is done sympathetically. >> >> Neither approach is great if you holistically approach this task as >> "making it correct at all times", and it is easy to confect scenarios >> that result in something that is semantically wrong, but syntactically >> correct; something that is plain wrong, both semantically and >> syntactically; and something that is occasionally correct. >> > > I see what you mean, but to me semantically _and_ syntactically correct > is the benefit we should pursue when we actually have the parse tree. > The current implementation will semantically correct in many interesting > cases, such as the one I outlined, and is a huge improvement to the > current "transpose-words"-like behavior. > There is no such thing as "syntactically correct" if you allow a user unfettered access to type in a buffer. Merely typing in the wrong place will break that promise. And who are we to judge what someone writes and where? The resting state of all code is "almost always broken" as you're typing out your code. >> 'Like' siblings are an easy way out of this mess with the caveat, as >> you'll see, but now you need to carefully pluck the right nodes from >> the tree! >> >> Consider the node type `pair' in a dict in Python. They are easily transposable for >> that very reason, notwithstanding the anonymous "," node betwixt them. >> >> That is why Combobulate has a list of stuff that it can safely >> transpose, and for everything else it defaults to the "classic" >> transpose. >> > > Yeah, such an approach seems reasonable, and there is already precedence > in defining such "things" in Emacs. As for the default fallback, I'll > see what I can do in the "treesit-transpose-sexps" function. The > machinery in transpose-subr and friends is a little finicky, so to > adhere to that mechanism isn't the easiest thing. > Sure. But please be careful when you make changes to `transpose-subr' (or `transpose-subr-1') so that they don't break its existing contract with its current users. It is a *very* powerful set of commands that can swap arbitrary tracts of text. >>>> >>>> Worse, it's not possible to revert to the old behaviour (see >>>> bug#60654) >>>> >>>> >> >> Thanks for fixing that! >> > > No problem - hopefully it is installed pretty soon. > > Theo