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#67036: 30.0.50; treesit-forward-sexp not working properly in ruby-ts-mode Date: Wed, 29 Nov 2023 09:04:14 +0200 Organization: LINKOV.NET Message-ID: <86msuxulvt.fsf@mail.linkov.net> References: <86bkc2nktq.fsf@mail.linkov.net> <83a5r2dw25.fsf@gnu.org> <45795de5-2064-3ab9-3cbb-c1b2018faf7c@gutov.dev> <864jh776bm.fsf@mail.linkov.net> <5a8d4404-47ec-9190-d80f-edc1fca26cf3@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31341"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) Cc: Eli Zaretskii , 67036@debbugs.gnu.org, Yuan Fu To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 29 08:22:01 2023 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 1r8EtV-0007zo-JC for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 29 Nov 2023 08:22:01 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r8EsV-0002mv-2y; Wed, 29 Nov 2023 02:20:59 -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 1r8EsQ-0002ld-Mq for bug-gnu-emacs@gnu.org; Wed, 29 Nov 2023 02:20:54 -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 1r8EsQ-0001rH-Dg for bug-gnu-emacs@gnu.org; Wed, 29 Nov 2023 02:20:54 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r8EsX-0005Gu-LY for bug-gnu-emacs@gnu.org; Wed, 29 Nov 2023 02:21:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Nov 2023 07:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67036 X-GNU-PR-Package: emacs Original-Received: via spool by 67036-submit@debbugs.gnu.org id=B67036.170124245720240 (code B ref 67036); Wed, 29 Nov 2023 07:21:01 +0000 Original-Received: (at 67036) by debbugs.gnu.org; 29 Nov 2023 07:20:57 +0000 Original-Received: from localhost ([127.0.0.1]:48666 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r8EsT-0005GO-AU for submit@debbugs.gnu.org; Wed, 29 Nov 2023 02:20:57 -0500 Original-Received: from relay4-d.mail.gandi.net ([2001:4b98:dc4:8::224]:35713) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r8EsR-0005G8-1r for 67036@debbugs.gnu.org; Wed, 29 Nov 2023 02:20:56 -0500 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id E806CE0004; Wed, 29 Nov 2023 07:20:39 +0000 (UTC) In-Reply-To: <5a8d4404-47ec-9190-d80f-edc1fca26cf3@gutov.dev> (Dmitry Gutov's message of "Wed, 29 Nov 2023 00:15:50 +0200") 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:275197 Archived-At: >>>>> + # from "elsif" and "then" C-M-f should jump to next "elsif"/"else" >>>>> if a == 2 then >>>>> puts "hello" >>>>> elsif a == 3 >>> >>> Try out the change referenced above, but it doesn't do exactly >>> this. Because the tree-sitter parse tree doesn't match the intuition you >>> described above. >> Thanks for adding "then" and "else" that works not bad. >> Then "elsif" could be added as well. > > You can try it and report back. My impression is that it made navigation > worse: the "elsif" nodes are not siblings of one another, they are > nested. So it doesn't exactly match your expectations. Now I tried and indeed it does wrong thing: jumps to the end of the last "else" instead of the end of own block because they are nested. But maybe possible to skip "condition" and jump to the end of its "consequence" before "alternative"? >>> Also, interactive forward-sexp never reports "No next sexp" when inside >>> parens or begin...end. It will do forward-up-list instead. >> On the one hand, it's inconsistent with the default non-treesit behavior >> of >> forward-sexp. On the other hand, the default behavior is too annoying >> when it screams all the time with "Containing expression ends prematurely!" >> instead of doing something useful. > > Looks like I have been spoiled by Paredit's paredit-forward which catches > such errors and does the appropriate thing. Might be nice to bring this > behavior to Emacs as forward-sexp-command, for example. Agreed, at least as opt-in. >>>>> +# when point is after @, C-M-f should jump to the end of symbol >>>>> zzz @abc, >>>>> 4 >>> >>> This is something that would need to be changed somewhere inside >>> treesit-forward-sexp (or treesit--navigate-thing). The default forward-sexp >>> behaves differently when in the middle of a symbol. >> Agreed, more general changes are needed when point is inside symbols, >> strings, comments, etc. > > This is regarding behavior "inside" a thing as understood by > treesit. Unrelated to Emacs's syntactic entities. "Inside a thing" could be handled the same way as "inside strings/comments". >>>>> +# C-M-f on '[' doesn't jump to after ']' >>>>> +hash['key'] >>>>> + >>> >>> As discussed previously, there is no specific node which spans from [ to >>> ]. Some custom code could probably be written (there *are* leaf nodes for [ >>> and ]), but the current capabilities of treesit-thing-settings don't offer >>> a good way to plug that in. >> Like for point inside strings, this might require more general changes >> that take into account syntax tables. > > Possibly, but I expect a solution that doesn't use the syntax table would > be tried first. Since there is no available information from treesit, handling treesit-forward-sexp inside strings/comments could forward to the syntax table like `prog-fill-reindent-defun' forwards to `fill-paragraph'.