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 16:34: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> <87359h1ybt.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="30646"; 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 22:35:32 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 1p5ZPX-0007gL-LW for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Dec 2022 22:35:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p5ZP5-0004Ka-Gs; Wed, 14 Dec 2022 16:35:03 -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 1p5ZP2-0004K7-TL for emacs-devel@gnu.org; Wed, 14 Dec 2022 16:35:00 -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 1p5ZOx-0007rb-7U; Wed, 14 Dec 2022 16:34:56 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BCB2A1004AD; Wed, 14 Dec 2022 16:34:50 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 1E6EE10002F; Wed, 14 Dec 2022 16:34:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1671053689; bh=dLc05hXnjvtvhAz0AMXc+XYKJeZWrqdJyZXPVWWQf5I=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=EAGOjzMH4+uyEyI3F6Per+WgltP2jNBYpbakzNqr+iyVpxTomTj6DTD9sJ6JrseEp nzeF02ejFpycBui//UXhPGBxUnejAEPbmpSTqF97vMr093gR0yO/PLhRrxlYhWcj3A Frg+6Nk/cMxzsJowMAhNElz8hLPBeCpL6PjW5oJfdhEN/qUJF1Trsx7mdbxWEL3TQK VaVAsSnIRfk+inEbs5rNa9KWuUx/8QcbieRYVbHzGJtVxY0jbIqRNTg8rQKZLNFeCF 30KNI5bSXsW07vDcC3n5+aagau/i8ZaSDuE4sp5bJcYkJrmyFzMlV5eDIYKxZRDx2S EFkLP88GI02Sw== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EC88D120F8F; Wed, 14 Dec 2022 16:34:48 -0500 (EST) In-Reply-To: <87359h1ybt.fsf@thornhill.no> (Theodor Thornhill's message of "Wed, 14 Dec 2022 22:15:34 +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:301417 Archived-At: > Great. It seems there has been almost no development, nor documentation > done in this area for a long time. Should I try to improve on this part > of the code while I'm at it? That would be welcome, yes. > Yeah, that's what I'm thinking too. I'm just thinking we should be > clear on what a word/sexp/sentence/paragraph/defun etc is in non-lisp > and non-human languages. In the context of SMIE I came up with a usable meaning for sexp (which I've been trying to explain in this thread), but for sentence and paragraph it seems harder and is likely to depend on the specifics of the language (e.g. for some languages "sentence" might be mapped to "instruction" or maybe "instruction that doesn't itself contain nested instructions", but some languages don't have a notion of instruction). >>> Now I'm having issues where movement over sexps ends up not in the >>> same place. >> Same place as? > IIRC there's no guarantee that the movement sequence used for > transpose-sexp moves over the same blocks of code, so in non-lisp > languages there's no real semantic to go from. I guess in general it can be difficult to be consistent, indeed. In SMIE I preserve the following (or at least I try to): infix ^ ^ ^ ^ AB AE BB BE if `transpose-sexp` swaps FOO and BAR, then `forward-sexp` from AE goes to BE and `backward-sexp` from BB goes to AB. But when you start to consider mixfix syntax it can become much less clear what needs to be done. I don't think we should worry too much if `transpose-sexp` and `forward/backward-sexp` don't align 100% is all cases: we should strive to keep them consistent, but it's OK to break down in corner cases. Stefan