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 18:19:55 -0500 Message-ID: References: <87wn6whete.fsf@thornhill.no> <87r0x3gnv5.fsf@thornhill.no> <04BB786A-3ED1-4918-8583-17AA01A1E453@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="23576"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Theodor Thornhill , emacs-devel@gnu.org, eliz@gnu.org To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 14 00:20:36 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 1p5EZf-0005u9-93 for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Dec 2022 00:20:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p5EZB-0000Hm-9O; Tue, 13 Dec 2022 18:20:05 -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 1p5EZ9-0000He-Ut for emacs-devel@gnu.org; Tue, 13 Dec 2022 18:20:04 -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 1p5EZ7-0006xY-FC; Tue, 13 Dec 2022 18:20:03 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 76DA980686; Tue, 13 Dec 2022 18:19:58 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 9B8918025B; Tue, 13 Dec 2022 18:19:56 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1670973596; bh=fqmMVqNM+TTfFhfEW3sob9hDjSJZbVrfzblQwkxKEvU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=HQSnvsodepIsrtzAIKkD4C0aPegy5HEkIZ5QPBGDI4SiojHhuuiaLZxCvxxlZmVHv BFSJtewNOQYKaiVCdRY9ewgagyZSrhucIPCGxxiwU5/e8E430tDRt+3J+P1aYGKOMR KEAHPL8KjESQon4wOtMwJFtqooGppkNYIP2yUJi0fGhlm43z4lYzDSlwzyJvvLMw4E cLKQU+Q1aw8GZ3NmOjpqucBnuaPrK05INEipvbaBAS9opKiLfjRuNUroEVIaf4zsNJ t2SI4Lk1dlYhE4jS5KNSl3T2YSW1VI8TdP9DumxuIpnYER59OOb6H4SRTJ+SC38/1Q dHTonDwcYF+Lw== Original-Received: from pastel (unknown [45.72.193.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 68C27123041; Tue, 13 Dec 2022 18:19:56 -0500 (EST) In-Reply-To: <04BB786A-3ED1-4918-8583-17AA01A1E453@gmail.com> (Yuan Fu's message of "Tue, 13 Dec 2022 11:53:18 -0800") 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:301365 Archived-At: >>> I mean, what construct is each one expected to jump over? >> In my book "sexp" movement should jump over subtrees of the AST. > It=E2=80=99s pretty hard to judge which subtree to move over at a given p= oint in an > AST. For example, when point is at | in the following text: > > (|X.y(z), alpha) > > Should point move over X, or X.y, or X.y(z)? All three subtrees has their > beg=3D(point). Exactly. It's even a bit worse: I'd also argue that an additional valid choice is to move over the whole "X.y(z), alpha". The semantics I opted for in SMIE is to choose the smallest/deepest subtree. That's what best matches the previous behavior of `forward-sexp`. If the users want to move over larger units they have to place their point elsewhere (e.g. if it's just before ".", then moving over "y" wouldn't make sense because "y" is attached to "y(z)" and not to ".", only "y(z)" is attached to "."). > 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 children = 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 abstra= ct list, > the argument list. 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`). Stefan