From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov 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: Tue, 01 Oct 2024 20:49:39 +0300 Organization: LINKOV.NET Message-ID: <86ed4zg1cc.fsf@mail.linkov.net> 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> 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="18820"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu) Cc: Eli Zaretskii , Mickey Petersen , 73404@debbugs.gnu.org To: Yuan Fu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 01 19:57:25 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 1svh7l-0004fI-6E for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Oct 2024 19:57:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1svh7S-0004M0-BB; Tue, 01 Oct 2024 13:57:06 -0400 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 1svh7Q-0004Li-2f for bug-gnu-emacs@gnu.org; Tue, 01 Oct 2024 13:57:04 -0400 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 1svh7P-0006OW-QG for bug-gnu-emacs@gnu.org; Tue, 01 Oct 2024 13:57:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=iuYW60/DTB8mgv0dr71f9WtXO3nL+dNQzoMvLJ7Juek=; b=LG9Et/pBz9elw+KPl8RlWniVybBgBBTleLrvAFTm26FIndT5u6TaLUUMAx8eV+8li6PbJiypQHosIh53LEBZcJA0q3m4OqyAAGK0iQfZjIyZPWHqnlCtWGJJgTcKY5bBeNdNud1kgowMQk2YIiw154xjxnx0EgsuSsMQ/9zYGMwm3yPaW5KIcICqy09lMCJyhXn3dCArc/C/59FSDRaTLL8mEgp6+jZwrN4W8tMeDoVf4Aw+pjAdL7Cca8CUG0Sne7MyR8bfdx3ei4qunT7vhtg7jLfObduXcSxpgGCFAz+FSJ5Ny6RPz/DyJlwRSDRiQ3Kb0BaUDZ3Ff5aqrc+lyA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1svh7O-0002q1-R1 for bug-gnu-emacs@gnu.org; Tue, 01 Oct 2024 13:57:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Oct 2024 17:57:02 +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.172780536810846 (code B ref 73404); Tue, 01 Oct 2024 17:57:02 +0000 Original-Received: (at 73404) by debbugs.gnu.org; 1 Oct 2024 17:56:08 +0000 Original-Received: from localhost ([127.0.0.1]:52756 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svh6W-0002os-1x for submit@debbugs.gnu.org; Tue, 01 Oct 2024 13:56:08 -0400 Original-Received: from relay8-d.mail.gandi.net ([217.70.183.201]:51885) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svh6R-0002oT-MG for 73404@debbugs.gnu.org; Tue, 01 Oct 2024 13:56:06 -0400 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id 6A2831BF203; Tue, 1 Oct 2024 17:55:57 +0000 (UTC) In-Reply-To: (Yuan Fu's message of "Mon, 30 Sep 2024 20:57:36 -0700") X-GND-Sasl: juri@linkov.net 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:292774 Archived-At: > The user can modify treesit-thing-settings to alter the behavior of > sexp navigation, they don’t necessarily need to use > js--treesit-sexp-nodes. Maybe we should add a test for > (treesit-thing-defined-p 'sexp nil) in treesit-forward-sexp? I tried to do something like this, and everything works nicely with: @@ -2289,11 +2289,10 @@ treesit-forward-sexp (node-at-point (treesit-node-at (point) (treesit-language-at (point))))) (or (when (and node-at-point - ;; Make sure point is strictly inside node. - (< (treesit-node-start node-at-point) - (point) - (treesit-node-end node-at-point)) - (treesit-node-match-p node-at-point 'text t)) + (or (treesit-node-match-p node-at-point 'text t) + (not (treesit-thing-at + (if (> arg 0) (point) (1- (point))) + (treesit-thing-definition 'sexp nil))))) (forward-sexp-default-function arg) t) (if (> arg 0) The new logic is the following: if there is no sexp thing defined at point, then fall back to 'forward-sexp-default-function'. Then after (setq js--treesit-sexp-nodes '("binary_expression")) 'C-M-f' in e.g. export const add = (a, b) => -!-a + b; moves point to export const add = (a, b) => a + b-!-; The condition (if (> arg 0) (point) (1- (point))) above is necessary to allow 'C-M-b' to move back to: export const add = (a, b) => -!-a + b; Also the condition to make sure point is strictly inside node was removed to handle the case when point was at the beginning of the buffer: -!- export const add = (a, b) => a + b; to move after export-!- const add = (a, b) => a + b; by 'forward-sexp-default-function'. > Your second example sounds useful, but right now the premise of tree-sitter > sexp movement is to use the parse tree primarily, and only use the default > sexp movement for comments and strings. What you envisioned seems to be the > other way around: use default sexp movement by default, and only use > tree-sitter movement under certain conditions. Is that few lines of change > able to make such big difference in the logic? I think we need to support both ways: 1. opt-out - where sexp-thing definition is used by default, and only text-thing allows users to override it; 2. opt-in - where 'forward-sexp-default-function' is used by default, and user can explicitly define what sexp-things are preferable for navigation by treesit. Then in the latter case the users could prefer to use treesit sexp navigation only for constructions with "invisible parens". For example, in Ruby there are two interchangeable syntaxes for code blocks: 1. curly braces {...} that are already handled by 'forward-sexp-default-function'; 2. do...end that can't be handled by 'forward-sexp-default-function', so treesit is coming to the rescue for the case of such implicit braces.