From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#73404: 30.0.50; [forward/kill/etc]-sexp commands do not behave as expected in tree-sitter modes Date: Thu, 12 Dec 2024 09:40:57 +0200 Message-ID: <86bjxh1h86.fsf@gnu.org> References: <87plox4mtp.fsf@masteringemacs.org> <87frpm20t7.fsf@masteringemacs.org> <8634lmbs8t.fsf@gnu.org> <87bk0a1u0o.fsf@masteringemacs.org> <86tte2a5o3.fsf@gnu.org> <877cay1lqt.fsf@masteringemacs.org> <86frpma06f.fsf@gnu.org> <86ikueiekp.fsf@mail.linkov.net> <86ed4zg1cc.fsf@mail.linkov.net> <87zflac68t.fsf@mail.linkov.net> <87jzcdlxdp.fsf@mail.linkov.net> <87o71jocgs.fsf@mail.linkov.net> <5192B278-66C0-48AE-B881-E57CCBB6B501@gmail.com> <87frmtbc9z.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16558"; mail-complaints-to="usenet@ciao.gmane.io" Cc: theo@thornhill.no, casouri@gmail.com, mickey@masteringemacs.org, monnier@iro.umontreal.ca, 73404@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 12 08:42:15 2024 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 1tLdpu-00045f-QO for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 12 Dec 2024 08:42:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tLdpk-0005y6-P0; Thu, 12 Dec 2024 02:42:04 -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 1tLdpi-0005xe-JR for bug-gnu-emacs@gnu.org; Thu, 12 Dec 2024 02:42:02 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tLdpi-0006vT-8U for bug-gnu-emacs@gnu.org; Thu, 12 Dec 2024 02:42:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-version:References:In-Reply-To:From:Date:To:Subject; bh=wcp5LueQE6cSq3gzt/YgZ1PnzYzSX/i44lwvpLKA7oU=; b=FSvqMOjROViZuSYfx0ALtLl6k75vYIer6Z6NsbdmNk5PZZHchedNphCbVdcsCuy1oO150Xfa8+eL1K04wvY5DzSTtZrEWs6dTZ/a+7hlsnAnVZi5Q1rlzIPXxZ2WMA1IJ79s5hb+om8QfPSH9Y1EXqkjwUxZ0qpxJwJCnthCNOzrmTrc+GfQtfPfEUtMH8t9vt733/3fndDcLH0Z/sUGn8W2OIUc5n7HvtjRSLr2kZaV4EJZFzJPew7oaW7R3leHs6wJhAWzL4YlWr8WYPbok3w9EnkYtv8THooy32029yV3gcLi/TB9+65JxcMzegyerEh2yE7Gj0pSNpEuSixSuQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tLdph-0004Pj-QB for bug-gnu-emacs@gnu.org; Thu, 12 Dec 2024 02:42:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Dec 2024 07:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73404 X-GNU-PR-Package: emacs Original-Received: via spool by 73404-submit@debbugs.gnu.org id=B73404.173398928016898 (code B ref 73404); Thu, 12 Dec 2024 07:42:01 +0000 Original-Received: (at 73404) by debbugs.gnu.org; 12 Dec 2024 07:41:20 +0000 Original-Received: from localhost ([127.0.0.1]:37445 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tLdp2-0004OU-1b for submit@debbugs.gnu.org; Thu, 12 Dec 2024 02:41:20 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:44404) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tLdoz-0004OB-JO for 73404@debbugs.gnu.org; Thu, 12 Dec 2024 02:41:18 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tLdos-0006dK-8p; Thu, 12 Dec 2024 02:41:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=wcp5LueQE6cSq3gzt/YgZ1PnzYzSX/i44lwvpLKA7oU=; b=W7xb5TbEIMLgxI0A1efo 2W7Y+7TQPqEvpoaWToaPaZ5ojwssxADXvolQcTCsFGVePDIGsMSLDUQTNjyq/qmMwcY351mjBIQ/0 Ys7//NnSxlejOeFXnj4m2ahxwHQHe6XkFdd6tVrevwnZ53CVEjMiMNJXfXUBv1t0YSMRmuFLsdgLt 2lJvzWwbihRPFIX5U9J3X34hNQJ3enCZSz0nr+55XySROsXq7gmilMJtJbmRhFpE0mYMUvxzzEqRl e+YYbistvu14uVMwAc3RmIk7aF/0kHtWxMtCpd37dSiN67XTfr6WZr7N8uj0/hRHW9sywgzEp6ZCY 9ruLZ5fGbawMvA==; In-Reply-To: <87frmtbc9z.fsf@mail.linkov.net> (message from Juri Linkov on Thu, 12 Dec 2024 09:17:44 +0200) 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:296889 Archived-At: > From: Juri Linkov > Cc: Stefan Monnier , Eli Zaretskii > , Mickey Petersen , > 73404@debbugs.gnu.org, Theodor Thornhill > Date: Thu, 12 Dec 2024 09:17:44 +0200 > > >>> Ah, this matches my idea of defining sexp in other languages as “repeatable > >>> construct/list-like construct”. We went with “every syntactic construct” at > >>> the time, which I didn’t object to, but I’m definitely happier with the > >>> repeatable construct approach. Including Stefan and Theo since they were > >>> part of the original sexp navigation discussion. > >> > >> FWIW, we have both `forward-list` and `forward-list` and the new > >> behavior you suggest sounds closer to the historical behavior of > >> `forward-list` than `forward-sexp`. > > > > Actually, what’s the difference between forward-list and forward-sexp? > > I always thought they are the same at least for Lisp. > > forward-sexp moves over a balanced parenthetical group like > forward-list does. Plus forward-sexp also moves over an atom > such as a symbol, a number. > > The problem is that treesit adds too much structural information > to such simple things as a symbol and a number. For example, in js > a simple keyword "export" gets the "(export_statement export" subtree, > Another keyword "const" gets "(lexical_declaration kind: const", etc. > > Therefore for such symbols forward-sexp needs to bypass the structure > and use simpler syntactic information to move over them like on a flat list. If you mean we should ignore the information provided by tree-sitter and instead use our own syntactic information, then that sounds wrong to me, FWIW. Why cannot we understand enough of the tree-sitter structural information to move like we want? Presumably, the structural information provided by tree-sitter is a portion of a parse tree, which to me means we should be able to move between the parse tree's nodes as long as we understand the tree and can interpret it in our terms. Aren't there some grammar-agnostic traits of tree-sitter nodes that would allow us to interpret the nodes in language-independent terms? If that is not available, then each major mode will have to provide treesit.el with a way to interpret the tree-sitter nodes of the corresponding grammar in a way that will allow sexp movement, thus providing an abstraction layer that treesit.el could use for the movement commands.