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 09:01:55 -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> 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="31438"; 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 15:45:28 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 1p5T0h-0007xA-W8 for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Dec 2022 15:45:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p5SLD-0004uo-HG; Wed, 14 Dec 2022 09:02:35 -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 1p5SKh-0004ot-NS for emacs-devel@gnu.org; Wed, 14 Dec 2022 09:02:11 -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 1p5SKf-0000xR-H9; Wed, 14 Dec 2022 09:02:03 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 70EC380068; Wed, 14 Dec 2022 09:01:59 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A6F3280723; Wed, 14 Dec 2022 09:01:57 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1671026517; bh=krzZtKy+leNZcTbk1ZOjwu7XGflVPbk9kSNA8uxwBk8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hf9x6+04cQWZ3msB7pZcKmUHpgcPSzYr0+o6VbcBKwfcmfrnc8BSymqx1FXRrOevv mKUANM5e1Y9Bewidiu9sIeiT5GRInijaqpU9BgMlnAFYeJEMdoRRH33ypdioc6L9FQ 9q5qZkpdSmoKH2ZPgEiRZJ5wgVWqED+Yi7/foq/gciJktRz518hZqg7YtgMgo+IHPJ RUF/65oFUjdo3m8O+GUWA6qJ4+mMZKOw/CAetCqd17rcNje54fPf+H+IXiK4akVOFi WdRieDcDnmP3c6xm0Fo9n/aGWscheF7oeO46YlB6xX/iZoOn0ZykQkbgzkHDVGWP33 PcMHZ4YAg4WNw== Original-Received: from pastel (unknown [45.72.193.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7AB1112039B; Wed, 14 Dec 2022 09:01:57 -0500 (EST) In-Reply-To: <4E3940CA-67A6-45B7-8785-4E60FDECCDFB@gmail.com> (Yuan Fu's message of "Wed, 14 Dec 2022 00:14:12 -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:301391 Archived-At: > I would argue that the purpose of forward-sexp is to move over items in > a list. There are different ways to look at it. In the Lisp context where it emerged, we only have "identifiers" and "parenthesized thingies", so that doesn't give much guidance about what to do in-between. The semantics I chose for SMIE is what I found to be closest to past practice. > Always going for the smallest subtree doesn=E2=80=99t seem to align with = it. > Take that example above, going across the smallest subtree means > moving over X, then moving over =E2=80=9C.=E2=80=9D, No: when you're left of ".", as in "(X|.y(z), alpha)", the SMIE semantics of `forward-sexp` moves over ".y(z)", i.e. to "(X.y(z)|, alpha)" > that doesn=E2=80=99t feel like what forward-sexp should do to me. Indeed, moving just over "." would be very far from my understanding of what `forward-sexp` intends to do. > You mean in the following code > > int a =3D 0[1]; > int b =3D 1;[2] > > Forward-sexp would move [1] to [2]? No, SMIE's `forward-sexp` moves from int a =3D 0|; int b =3D 1; to int a =3D 0; int b =3D 1|; [ You can try it by installing Tuareg and moving around in an OCaml file, for example. ] and when moving backward it moves from int a =3D 0; int b =3D 1;| to int a =3D 0;| int b =3D 1; > But if we move over the smallest > subtree, I=E2=80=99d imagine it only move across the semicolon after [1]. In my view ";" is not a substree. It's the node of a substree. We can't actually move over a proper subtree in that case because there is no substree whose left boundary starts right before the ";", so the closest is to move over the ";" *plus* its right child. > 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. Moving point is the way to tell SMIE's `forward-sexp` which level of the tr= ee we want to navigate. I don't believe Emacs can reliably guess the right level, and I don't believe choosing an arbitrary level for the users serves them best either. I can imagine other ways to specify the intended tree level, tho: maybe we could have a kind of prefix command for that. E.g. a new command that would work a bit like `C-M-u` (or its younger sibling `expand-region`) but would only affect the next sexp command instead. > I want to type a single binding and move to where I want, and > type that binding multiple times to move multiple steps. I don't think a single binding can always jump to where you want. That would require magic :-) But yes, SMIE's `forward-sexp` does work well when repeated to jump over N instructions, it was indeed an important design goal. Stefan