Subject: bug#77727: closed (Re: [PATCH] Limit rust-ts-specific comment-start check to rust-ts (bug#77727))

From: [email-masked] (GNU bug Tracking System)
Date: Fri, 18 Apr 2025 23:36:03 +0000

Your bug report

#77727: tsx-ts-mode: fill-paragraph doesn't work for doc-comments

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
77727: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=77727
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: [PATCH] Limit rust-ts-specific comment-start check to rust-ts (bug#77727)
From: Yuan Fu <[email-masked]>
To: Konstantin Kharlamov <[email-masked]>
Cc: [email-masked]
Date: Fri, 18 Apr 2025 16:35:13 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

> On Apr 18, 2025, at 2:48 AM, Konstantin Kharlamov <[email-masked]> wrote:
> 
> On Wed, 2025-04-16 at 22:58 -0700, Yuan Fu wrote:
>> 
>> 
>>> On Apr 11, 2025, at 4:51 AM, Konstantin Kharlamov
>>> <[email-masked]> wrote:
>>> 
>>> On Fri, 2025-04-11 at 11:34 +0300, Konstantin Kharlamov wrote:
>>>> CC: Yuan Fu as the author of the code in question.
>>>> 
>>>> What happens in the code makes sense: since the comment resides
>>>> at
>>>> top-
>>>> level, the parent of any top-level statement (returned by
>>>> (treesit-
>>>> node-parent node)) is, well, beginning of a buffer.
>>>> 
>>>> So the question is, why the check works that way.
>>> 
>>> Please see the attached patch, it'd seem this is exactly the fix
>>> that's
>>> expected here. Basically, the problematic check is specific to Rust
>>> treesitter mode, so shouldn't be executed in other languages. The
>>> patch
>>> factors out the entire check to a separate function and adds
>>> additional
>>> condition of (eq major-mode 'rust-ts-mode).
>>> 
>>> Tested in tsx-ts-mode, it fixes the problem.
>>> <1.patch>
>> 
>> Thanks! Your analysis is correct. But I don’t want to hard-code rust-
>> ts-mode in the function, since modes with other names can very well
>> use rust parser. I pushed 9d43715baa5 that operates in the similar
>> vein as your patch. Instead of checking for the current major mode, I
>> tighten the condition by adding an additional check that ensure the
>> parent node is a comment node. So now if the parent node is the root
>> node (as in your initial example), the condition should fail. Please
>> see if it fixes your problem.
>> 
>> Yuan
> 
> Thank you, I confirm the problem is fixed, so bug can be closed.

Great, closing the report.

Yuan

Subject: tsx-ts-mode: fill-paragraph doesn't work for doc-comments
From: Konstantin Kharlamov <[email-masked]>
To: [email-masked]
Date: Fri, 11 Apr 2025 11:10:34 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

Steps to reproduce:

1. Open `test.tsx` with the following content:

    // File description
    /**
     * Lorem ipsum dolor sit amet consectetur adipiscing elit. Quisque faucibus ex sapien vitae pellentesque sem placerat. In id cursus mi pretium tellus duis convallis.
     */
2. Try to "fill" the Lorem ipsum text.

Result: nothing changes, the text doesn't get "filled".

---------

I dug into it, the bug resides in the following condition in
`c-ts-common--fill-paragraph`:

                …
                ;; In rust, NODE will be the body of a comment, and the
                ;; parent will be the whole comment.
                (if-let* ((start (treesit-node-start
                                  (treesit-node-parent node))))
                    (save-excursion
                      (goto-char start)
                      (looking-at "//"))))
                …

The problem is that "(treesit-node-start (treesit-node-parent node))" returns 1.
That happens disregarding the amount of code between the "// File description"
line and where "/* Lorem ipsum…" is. In the actual code there's 51 lines in
between.

Why treesit-node-start does that I don't know, so I decided to report it.