all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Yuan Fu <casouri@gmail.com>
To: Theodor Thornhill <theo@thornhill.no>
Cc: leungbk@posteo.net, 59853@debbugs.gnu.org
Subject: bug#59853: 30.0.50; tree-sitter modes have unexpected  beginning-of-defun behavior
Date: Tue, 20 Dec 2022 21:28:38 -0800	[thread overview]
Message-ID: <03F610B9-9B11-4AB8-BE17-A8CB777AE73E@gmail.com> (raw)
In-Reply-To: <87lenlnjc1.fsf@posteo.net>


Theodor Thornhill <theo@thornhill.no> writes:

> Brian Leung <leungbk@posteo.net> writes:
>
>> Theodor Thornhill <theo@thornhill.no> 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?
>>
>
> I believe it was the one I included as a patch here.
>
>>>> 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?
>>
>
> I understand.  I think that either we need to tweak the
> treesit-defun-type-regexp or make use of something like:
>
> (treesit-node-on (point) (point)) in the code that searches for
> beginning/end-of-defun.
>
> That code should return what you want, right?
>
>>>> 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.
>
> Yeah.  But I believe Yuan is cooking on some code wrt
> beginning/end-of-defun, so maybe we should just wait and see what he
> comes up with.

Oh wait, this report is about narrow-to-defun rather than
c-ts-mode-indent-defun, err that’s not fixed yet, because
beginning/end-of-defun doens’t use tree-sitter anymore (headache). I’ll
try to address this soon.

Yuan





  parent reply	other threads:[~2022-12-21  5:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-06  6:21 bug#59853: 30.0.50; tree-sitter modes have unexpected beginning-of-defun behavior Brian Leung
2022-12-06  8:31 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-06  8:41   ` Brian Leung
2022-12-06 10:36     ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-07  9:51       ` Brian Leung
2022-12-07 11:33         ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-09  3:35           ` Brian Leung
2022-12-09 15:59             ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-07 19:34 ` Yuan Fu
2022-12-21  5:24 ` Yuan Fu
2022-12-21  5:28 ` Yuan Fu [this message]
2022-12-22  8:59 ` Yuan Fu
2023-01-07 23:12 ` Yuan Fu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=03F610B9-9B11-4AB8-BE17-A8CB777AE73E@gmail.com \
    --to=casouri@gmail.com \
    --cc=59853@debbugs.gnu.org \
    --cc=leungbk@posteo.net \
    --cc=theo@thornhill.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.