From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Brian Leung Newsgroups: gmane.emacs.bugs Subject: bug#59853: 30.0.50; tree-sitter modes have unexpected beginning-of-defun behavior Date: Fri, 09 Dec 2022 03:35:21 +0000 Message-ID: <87h6y51bgk.fsf@posteo.net> References: <87lenlnjc1.fsf@posteo.net> <87k035vsph.fsf@thornhill.no> <87h6y8oq0x.fsf@posteo.net> <875yeox1hs.fsf@thornhill.no> <87mt7zplpf.fsf@posteo.net> <87k033zbw3.fsf@thornhill.no> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39283"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, 59853@debbugs.gnu.org To: Theodor Thornhill Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 09 04:52:16 2022 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 1p3UQq-000A0u-4M for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 09 Dec 2022 04:52:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p3UQf-0006un-Aq; Thu, 08 Dec 2022 22:52:05 -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 1p3UQd-0006ud-49 for bug-gnu-emacs@gnu.org; Thu, 08 Dec 2022 22:52:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p3UQc-0007wU-Os for bug-gnu-emacs@gnu.org; Thu, 08 Dec 2022 22:52:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p3UQc-0001Es-2L for bug-gnu-emacs@gnu.org; Thu, 08 Dec 2022 22:52:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Brian Leung Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Dec 2022 03:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59853 X-GNU-PR-Package: emacs Original-Received: via spool by 59853-submit@debbugs.gnu.org id=B59853.16705579024755 (code B ref 59853); Fri, 09 Dec 2022 03:52:02 +0000 Original-Received: (at 59853) by debbugs.gnu.org; 9 Dec 2022 03:51:42 +0000 Original-Received: from localhost ([127.0.0.1]:60919 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p3UQI-0001Ed-9O for submit@debbugs.gnu.org; Thu, 08 Dec 2022 22:51:42 -0500 Original-Received: from mout02.posteo.de ([185.67.36.66]:44641) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p3UQF-0001EX-Gp for 59853@debbugs.gnu.org; Thu, 08 Dec 2022 22:51:40 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 64BDE240103 for <59853@debbugs.gnu.org>; Fri, 9 Dec 2022 04:51:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1670557893; bh=lHMKhCJohm9zqc4SbpodBeXRBn5BXSjEOqYWfdN7nDA=; h=From:To:Cc:Subject:Date:From; b=pqmvw4OahMJc4bUDUJJ+ew7eTzISyAqi0G+XFO8XjtAs+sOQUtn1RU/rnpmP1WLOh 6YvE6fRWiStvRFDw7yt7WsR4AdINBAfF7o8eLwPJ4E0v8l0Hd3FR2yn8pfLL96wLLY dTi+5t9mkflWRt//vNeHrPtjP352fRtEqmHd9vjv8I592tLpLDRff/QNvVg3Nb4tJj gbOOLvm534Y8mHPdnWtUzy8Svt9L0RIKbI89T+olozeFX1qcdnAJ8kgupqNqSsVW5e Fv6pTauzlnYEm4UlYd01QPY/i+qj94zmHxSa8g7xLO7DnPH2R5taKNJLoJhvgPKinx E3TS/3tIpFHuQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4NSxsF1p81z9rxG; Fri, 9 Dec 2022 04:51:29 +0100 (CET) In-reply-to: <87k033zbw3.fsf@thornhill.no> 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:250353 Archived-At: Theodor Thornhill writes: >> 2. When point is anywhere in the first line of the class >> declaration, mark-defun highlights "void otherMethod()", >> instead >> of the entire class declaration. > > Yeah, I think I've fixed this in a patch I just submitted. Which commit are you referring to? >> 3a. When point is at the [*] in between someMethod and >> otherMethod, narrow-to-defun captures "void otherMethod()". I >> feel >> that since the methods inside the interface declaration have no >> bodies, it makes more sense to capture the entire interface >> definition if point is at [*]. > > Maybe, but I don't believe this is wrong either. Let me rephrase my request. Consider the following example: > class Cow implements Animal { > public void animalSound() { > // The body of animalSound() is provided here > System.out.println("The cow says: moo"); > } > > [*] > > public void sleep() { > // The body of sleep() is provided here > System.out.println("Zzz"); > } > } Both the methods have bodies. If point is at the [*], I would like for narrow-to-defun to capture the entire class declaration, since point is not really contained in either method. (For this particular example, java-mode presently agrees with java-ts-mode.) Is there a clean way of ensuring that, when point lies between (and is not contained in) those two methods, point is not treated as if it were in one of those methods' tree-sitter nodes? >> 3b. Arguably, even if point were on the method declarations, we >> might still want to (as plain java-mode does) capture the >> entire >> interface definition, since body-less method declarations don't >> feel especially defun-like. > > Maybe. Can you try applying the below patch and see if this > changes > anything for you? It captures the entire interface definition only when I remove "method_declaration" (which we probably want to keep) from the regexp.