From: Yuan Fu <casouri@gmail.com>
To: Theodor Thornhill <theo@thornhill.no>
Cc: Brian Leung <leungbk@posteo.net>, 59853@debbugs.gnu.org
Subject: bug#59853: 30.0.50; tree-sitter modes have unexpected beginning-of-defun behavior
Date: Wed, 7 Dec 2022 11:34:05 -0800 [thread overview]
Message-ID: <5172C572-732C-4F2E-ADFA-F88FD54895CE@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:
>>
>>> Not sure I can reproduce this.
>>
>> Sorry, I made a mistake in my description. I additionally noticed
>> additional odd results in java-ts-mode. Let me try again:
>>
>>> p[u]blic abstract class Class {
>>> public static interface Interface {
>>> void someMethod();
>>> [*]
>>> void otherMethod();
>>> [}]
>>> }
>
> Right - thanks! Now I understand what you describe. I'll try to answer
> them case by case.
>
>>
>> 1. When point is at the "u" in "public", narrow-to-defun cuts off
>> "pu" and moves point to "b".
>
> Yes, this definitely looks like a bug. This is probably because the
> whole 'public' keyword maps to the declaration, and we don't move to the
> actual beginning. I can look into this.
>
>> 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.
>
>> 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.
>
>> 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?
>
>> 4. When point is on the closing bracket of the interface
>> definition, narrow-to-defun captures
>>
>>> void otherMethod();
>>> }
>>> }
>>
>> which looks quite unusual to me.
>
> Yes, I agree with this one. My guess is that this is the same as number
> one.
>
> What do you think?
>
> Theo
There’s a discussion semi-related to this on emacs-devel, where Alan
mentioned this:
In CC Mode, it has been configurable via the user option c-defun-tactic
for somewhere between ten and fifteen years. When c-defun-tactic is t,
C-M-a/e go to the start/end of the top level defuns. When it is the
symbol go-outward, C-M-a/e move to the next start/end of defun, if any,
at the current level of class/namespace nesting, and move outwards to
the next level of class/namespace nesting when a class/namespace boundary
is reached.
If we add this option to tree-sitter, user could decide what bahavior
they want. I’m planning to work on that. Though there is already
something that can more-or-less do this: treesit-defun-prefer-top-level.
Yuan
next prev parent reply other threads:[~2022-12-07 19:34 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 [this message]
2022-12-21 5:24 ` Yuan Fu
2022-12-21 5:28 ` Yuan Fu
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=5172C572-732C-4F2E-ADFA-F88FD54895CE@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.