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

Previous Next

To reply to this bug, email your comments to 77727 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
To: bug-gnu-emacs <at> gnu.org
Subject: tsx-ts-mode: fill-paragraph doesn't work for doc-comments
Date: Fri, 11 Apr 2025 11:10:34 +0300

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.

Message #8 received at 77727 <at> debbugs.gnu.org (full text, mbox):

From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
To: 77727 <at> debbugs.gnu.org, casouri <at> gmail.com
Subject: bug#77727: tsx-ts-mode: fill-paragraph doesn't work for doc-comments
Date: Fri, 11 Apr 2025 11:34:38 +0300

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.

Message #11 received at 77727 <at> debbugs.gnu.org (full text, mbox):

From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
To: 77727 <at> debbugs.gnu.org, casouri <at> gmail.com
Subject: [PATCH] Limit rust-ts-specific comment-start check to rust-ts
 (bug#77727)
Date: Fri, 11 Apr 2025 14:51:44 +0300

[Message part 1 (text/plain, inline)]

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 (text/x-patch, attachment)]

Message #14 received at 77727 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
Cc: 77727 <at> debbugs.gnu.org
Subject: Re: [PATCH] Limit rust-ts-specific comment-start check to rust-ts
 (bug#77727)
Date: Wed, 16 Apr 2025 22:58:35 -0700

> On Apr 11, 2025, at 4:51 AM, Konstantin Kharlamov <Hi-Angel <at> yandex.ru> 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

Message #17 received at 77727 <at> debbugs.gnu.org (full text, mbox):

From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 77727 <at> debbugs.gnu.org
Subject: Re: [PATCH] Limit rust-ts-specific comment-start check to rust-ts
 (bug#77727)
Date: Thu, 17 Apr 2025 10:12:43 +0300

On Wed, 2025-04-16 at 22:58 -0700, Yuan Fu wrote:
>
>
> > On Apr 11, 2025, at 4:51 AM, Konstantin Kharlamov
> > <Hi-Angel <at> yandex.ru> 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

Well, FWIW latest master as of 2925ff6c538 doesn't even start for me:

    λ emacs -Q
    Loading loadup.el (source)...
    Dump mode: nil
    Using load-path (/usr/share/emacs/31.0.50/lisp /usr/share/emacs/31.0.50/lisp/emacs-lisp /usr/share/emacs/31.0.50/lisp/progmodes /usr/share/emacs/31.0.50/lisp/language /usr/share/emacs/31.0.50/lisp/international /usr/share/emacs/31.0.50/lisp/textmodes /usr/share/emacs/31.0.50/lisp/vc)
    Loading emacs-lisp/debug-early...
    Symbol's function definition is void: file-name-sans-extension

I tried jumping down between some commits and rebuilding, but it
doesn't go away.

Anyway, if you tested that the steps-to-reproduce don't reproduce the
problem anymore with you commit, I guess it's fine to close the bug.

Message #20 received at 77727 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
Cc: casouri <at> gmail.com, 77727 <at> debbugs.gnu.org
Subject: Re: bug#77727: [PATCH] Limit rust-ts-specific comment-start check to
 rust-ts (bug#77727)
Date: Thu, 17 Apr 2025 10:37:56 +0300

> Cc: 77727 <at> debbugs.gnu.org
> From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
> Date: Thu, 17 Apr 2025 10:12:43 +0300
> 
> On Wed, 2025-04-16 at 22:58 -0700, Yuan Fu wrote:
> >
> >
> > > On Apr 11, 2025, at 4:51 AM, Konstantin Kharlamov
> > > <Hi-Angel <at> yandex.ru> 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
> 
> Well, FWIW latest master as of 2925ff6c538 doesn't even start for me:
> 
>     λ emacs -Q
>     Loading loadup.el (source)...
>     Dump mode: nil
>     Using load-path (/usr/share/emacs/31.0.50/lisp /usr/share/emacs/31.0.50/lisp/emacs-lisp /usr/share/emacs/31.0.50/lisp/progmodes /usr/share/emacs/31.0.50/lisp/language /usr/share/emacs/31.0.50/lisp/international /usr/share/emacs/31.0.50/lisp/textmodes /usr/share/emacs/31.0.50/lisp/vc)
>     Loading emacs-lisp/debug-early...
>     Symbol's function definition is void: file-name-sans-extension
> 
> I tried jumping down between some commits and rebuilding, but it
> doesn't go away.

It looks like you invoke an installed Emacs?  IOW, did you say "make
install" after patching or updating from Git?  And did you make sure
the .pdmp pdumper file is updated by that?  The above seems to
indicate that Emacs cannot find the pdumper file for some reason.

Message #23 received at 77727 <at> debbugs.gnu.org (full text, mbox):

From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: casouri <at> gmail.com, 77727 <at> debbugs.gnu.org
Subject: Re: bug#77727: [PATCH] Limit rust-ts-specific comment-start check
 to rust-ts (bug#77727)
Date: Thu, 17 Apr 2025 11:19:37 +0300

On Thu, 2025-04-17 at 10:37 +0300, Eli Zaretskii wrote:
> > Cc: 77727 <at> debbugs.gnu.org
> > From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
> > Date: Thu, 17 Apr 2025 10:12:43 +0300
> > 
> > On Wed, 2025-04-16 at 22:58 -0700, Yuan Fu wrote:
> > > 
> > > 
> > > > On Apr 11, 2025, at 4:51 AM, Konstantin Kharlamov
> > > > <Hi-Angel <at> yandex.ru> 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
> > 
> > Well, FWIW latest master as of 2925ff6c538 doesn't even start for
> > me:
> > 
> >     λ emacs -Q
> >     Loading loadup.el (source)...
> >     Dump mode: nil
> >     Using load-path (/usr/share/emacs/31.0.50/lisp
> > /usr/share/emacs/31.0.50/lisp/emacs-lisp
> > /usr/share/emacs/31.0.50/lisp/progmodes
> > /usr/share/emacs/31.0.50/lisp/language
> > /usr/share/emacs/31.0.50/lisp/international
> > /usr/share/emacs/31.0.50/lisp/textmodes
> > /usr/share/emacs/31.0.50/lisp/vc)
> >     Loading emacs-lisp/debug-early...
> >     Symbol's function definition is void: file-name-sans-extension
> > 
> > I tried jumping down between some commits and rebuilding, but it
> > doesn't go away.
> 
> It looks like you invoke an installed Emacs?  IOW, did you say "make
> install" after patching or updating from Git?  And did you make sure
> the .pdmp pdumper file is updated by that?  The above seems to
> indicate that Emacs cannot find the pdumper file for some reason.

Yep, it's an installed Emacs.

I am not sure what do you mean by `.pdmp` file, I never touched them. I
see the resulting package has file /usr/lib/emacs/31.0.50/x86_64-pc-
linux-gnu/emacs-
8dc71cdb3ec816249f8467e350dff31faabf46305805586b479fc8f3412dbdbb.pdmp,
am I supposed to do something about it…? I looked through PKGBUILD (a
popular script used to assemble emacs from git as an Archlinux
package), and there's no mention of pdmp, so… Neither me, nor the
script ever touched this file, well, not directly at least.

Before I wrote this email I also tried doing a `make bootstrap` to make
sure there's no older artifacts that could cause it, but resulting
Emacs still produces same errors.

Message #26 received at 77727 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
Cc: casouri <at> gmail.com, 77727 <at> debbugs.gnu.org
Subject: Re: bug#77727: [PATCH] Limit rust-ts-specific comment-start check
 to rust-ts (bug#77727)
Date: Thu, 17 Apr 2025 13:53:42 +0300

> From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
> Cc: casouri <at> gmail.com, 77727 <at> debbugs.gnu.org
> Date: Thu, 17 Apr 2025 11:19:37 +0300
> 
> On Thu, 2025-04-17 at 10:37 +0300, Eli Zaretskii wrote:
> > >     λ emacs -Q
> > >     Loading loadup.el (source)...
> > >     Dump mode: nil
> > >     Using load-path (/usr/share/emacs/31.0.50/lisp
> > > /usr/share/emacs/31.0.50/lisp/emacs-lisp
> > > /usr/share/emacs/31.0.50/lisp/progmodes
> > > /usr/share/emacs/31.0.50/lisp/language
> > > /usr/share/emacs/31.0.50/lisp/international
> > > /usr/share/emacs/31.0.50/lisp/textmodes
> > > /usr/share/emacs/31.0.50/lisp/vc)
> > >     Loading emacs-lisp/debug-early...
> > >     Symbol's function definition is void: file-name-sans-extension
> > > 
> > > I tried jumping down between some commits and rebuilding, but it
> > > doesn't go away.
> > 
> > It looks like you invoke an installed Emacs?  IOW, did you say "make
> > install" after patching or updating from Git?  And did you make sure
> > the .pdmp pdumper file is updated by that?  The above seems to
> > indicate that Emacs cannot find the pdumper file for some reason.
> 
> Yep, it's an installed Emacs.
> 
> I am not sure what do you mean by `.pdmp` file, I never touched them.

Rebuilding Emacs produces a new .pdmp file, which the previous binary
will not load (because it doesn't fit it).  When you rebuild Emacs,
you need to invoke "make install" afterwards, to install the Emacs
binary and the auxiliary files, including the new .pdmp file, in the
place where Emacs expects to find it.  Did you run "make install"
after rebuilding?

> I
> see the resulting package has file /usr/lib/emacs/31.0.50/x86_64-pc-
> linux-gnu/emacs-
> 8dc71cdb3ec816249f8467e350dff31faabf46305805586b479fc8f3412dbdbb.pdmp,
> am I supposed to do something about it…? I looked through PKGBUILD (a
> popular script used to assemble emacs from git as an Archlinux
> package), and there's no mention of pdmp, so… Neither me, nor the
> script ever touched this file, well, not directly at least.

"make install" does what needs to be done with the .pdmp file: copies
it to the correct directory under the correct name.

> Before I wrote this email I also tried doing a `make bootstrap` to make
> sure there's no older artifacts that could cause it, but resulting
> Emacs still produces same errors.

If you run Emacs from the src directory of the build tree, does it
work?

Message #29 received at 77727 <at> debbugs.gnu.org (full text, mbox):

From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: casouri <at> gmail.com, 77727 <at> debbugs.gnu.org
Subject: Re: bug#77727: [PATCH] Limit rust-ts-specific comment-start check
 to rust-ts (bug#77727)
Date: Thu, 17 Apr 2025 14:09:54 +0300

On Thu, 2025-04-17 at 13:53 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
> > Cc: casouri <at> gmail.com, 77727 <at> debbugs.gnu.org
> > Date: Thu, 17 Apr 2025 11:19:37 +0300
> > 
> > On Thu, 2025-04-17 at 10:37 +0300, Eli Zaretskii wrote:
> > > >     λ emacs -Q
> > > >     Loading loadup.el (source)...
> > > >     Dump mode: nil
> > > >     Using load-path (/usr/share/emacs/31.0.50/lisp
> > > > /usr/share/emacs/31.0.50/lisp/emacs-lisp
> > > > /usr/share/emacs/31.0.50/lisp/progmodes
> > > > /usr/share/emacs/31.0.50/lisp/language
> > > > /usr/share/emacs/31.0.50/lisp/international
> > > > /usr/share/emacs/31.0.50/lisp/textmodes
> > > > /usr/share/emacs/31.0.50/lisp/vc)
> > > >     Loading emacs-lisp/debug-early...
> > > >     Symbol's function definition is void: file-name-sans-
> > > > extension
> > > > 
> > > > I tried jumping down between some commits and rebuilding, but
> > > > it
> > > > doesn't go away.
> > > 
> > > It looks like you invoke an installed Emacs?  IOW, did you say
> > > "make
> > > install" after patching or updating from Git?  And did you make
> > > sure
> > > the .pdmp pdumper file is updated by that?  The above seems to
> > > indicate that Emacs cannot find the pdumper file for some reason.
> > 
> > Yep, it's an installed Emacs.
> > 
> > I am not sure what do you mean by `.pdmp` file, I never touched
> > them.
> 
> Rebuilding Emacs produces a new .pdmp file, which the previous binary
> will not load (because it doesn't fit it).  When you rebuild Emacs,
> you need to invoke "make install" afterwards, to install the Emacs
> binary and the auxiliary files, including the new .pdmp file, in the
> place where Emacs expects to find it.  Did you run "make install"
> after rebuilding?

Yes, it's being run as `make DESTDIR="$pkgdir/" install`

> > I
> > see the resulting package has file /usr/lib/emacs/31.0.50/x86_64-
> > pc-
> > linux-gnu/emacs-
> > 8dc71cdb3ec816249f8467e350dff31faabf46305805586b479fc8f3412dbdbb.pd
> > mp,
> > am I supposed to do something about it…? I looked through PKGBUILD
> > (a
> > popular script used to assemble emacs from git as an Archlinux
> > package), and there's no mention of pdmp, so… Neither me, nor the
> > script ever touched this file, well, not directly at least.
> 
> "make install" does what needs to be done with the .pdmp file: copies
> it to the correct directory under the correct name.

Okay, so I just tried doing a `find -type f -name "*.pdmp" -delete`,
and then rebuilding Emacs (to make sure no pdmp files are stale), then
assembled/installed package. I see the file ends up is at

/usr/lib/emacs/31.0.50/x86_64-pc-linux-gnu/emacs-
e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5.pdmp

This is same location as for the "working" Emacs build:

/usr/lib/emacs/31.0.50/x86_64-pc-linux-gnu/emacs-
37634abbce82a9c44ab59298a6ed926eb3396ac970e12cc2c2798d93deb8eee8.pdmp

> > Before I wrote this email I also tried doing a `make bootstrap` to
> > make
> > sure there's no older artifacts that could cause it, but resulting
> > Emacs still produces same errors.
> 
> If you run Emacs from the src directory of the build tree, does it
> work?

Yes, if I run it as `./build/src/emacs -Q`, it does work. So apparently
it's something to do with installation… But I'm not doing anything odd,
it's plain old `make install` with DESTDIR set, used it for years…

Message #32 received at 77727 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
Cc: casouri <at> gmail.com, 77727 <at> debbugs.gnu.org
Subject: Re: bug#77727: [PATCH] Limit rust-ts-specific comment-start check
 to rust-ts (bug#77727)
Date: Thu, 17 Apr 2025 16:12:14 +0300

> From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
> Cc: casouri <at> gmail.com, 77727 <at> debbugs.gnu.org
> Date: Thu, 17 Apr 2025 14:09:54 +0300
> 
> > Rebuilding Emacs produces a new .pdmp file, which the previous binary
> > will not load (because it doesn't fit it).  When you rebuild Emacs,
> > you need to invoke "make install" afterwards, to install the Emacs
> > binary and the auxiliary files, including the new .pdmp file, in the
> > place where Emacs expects to find it.  Did you run "make install"
> > after rebuilding?
> 
> Yes, it's being run as `make DESTDIR="$pkgdir/" install`

What is the value of $pkgdir ?

> Okay, so I just tried doing a `find -type f -name "*.pdmp" -delete`,
> and then rebuilding Emacs (to make sure no pdmp files are stale), then
> assembled/installed package. I see the file ends up is at
> 
> /usr/lib/emacs/31.0.50/x86_64-pc-linux-gnu/emacs-
> e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5.pdmp

When you build Emacs, it shows the fingerprint, like this:

  Dumping under the name emacs.pdmp
  Dumping fingerprint: 189095568e4fae77c858f1c5071e36beaf86dbf632e161df634a1099dc31f876
  Dump complete

Is the fingerprint in your case identical to the name of the .pdmp
file (sans the extension)?

If it is identical, are you sure you are invoking the correct 'emacs'
executable?  How many Emacs executables do you have in the $pkgdir/bin
directory (from where you supposedly invoke Emacs), and what are their
names?

> This is same location as for the "working" Emacs build:

What is the "working" Emacs build, and how is it different from the
one that doesn't work?

> > If you run Emacs from the src directory of the build tree, does it
> > work?
> 
> Yes, if I run it as `./build/src/emacs -Q`, it does work.

Is the contents of the emacs.pdmp file in the source directory
identical to the contents of
/usr/lib/emacs/31.0.50/x86_64-pc-linux-gnu/emacs-e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5.pdmp?

Message #35 received at 77727 <at> debbugs.gnu.org (full text, mbox):

From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: casouri <at> gmail.com, 77727 <at> debbugs.gnu.org
Subject: Re: bug#77727: [PATCH] Limit rust-ts-specific comment-start check
 to rust-ts (bug#77727)
Date: Thu, 17 Apr 2025 21:12:19 +0300

On Thu, 2025-04-17 at 16:12 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
> > Cc: casouri <at> gmail.com, 77727 <at> debbugs.gnu.org
> > Date: Thu, 17 Apr 2025 14:09:54 +0300
> >
> > > Rebuilding Emacs produces a new .pdmp file, which the previous
> > > binary
> > > will not load (because it doesn't fit it).  When you rebuild
> > > Emacs,
> > > you need to invoke "make install" afterwards, to install the
> > > Emacs
> > > binary and the auxiliary files, including the new .pdmp file, in
> > > the
> > > place where Emacs expects to find it.  Did you run "make install"
> > > after rebuilding?
> >
> > Yes, it's being run as `make DESTDIR="$pkgdir/" install`
>
> What is the value of $pkgdir ?

It's /home/constantine/Projects/builds/emacs-git/pkg/emacs-git/

> > Okay, so I just tried doing a `find -type f -name "*.pdmp" -
> > delete`,
> > and then rebuilding Emacs (to make sure no pdmp files are stale),
> > then
> > assembled/installed package. I see the file ends up is at
> >
> > /usr/lib/emacs/31.0.50/x86_64-pc-linux-gnu/emacs-
> > e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5.pd
> > mp
>
> When you build Emacs, it shows the fingerprint, like this:
>
>   Dumping under the name emacs.pdmp
>   Dumping fingerprint:
> 189095568e4fae77c858f1c5071e36beaf86dbf632e161df634a1099dc31f876
>   Dump complete
>
> Is the fingerprint in your case identical to the name of the .pdmp
> file (sans the extension)?

Yes. I just rebuilt while saving the output, and there are 3
fingerprints mentioning lines:

Dumping fingerprint: e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5
Dumping fingerprint: e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5
/usr/bin/install -c -m 644 src/emacs.pdmp "/home/constantine/Projects/builds/emacs-git/pkg/emacs-git//usr/lib/emacs/31.0.50/x86_64-pc-linux-gnu"/emacs-`./src/emacs --fingerprint`.pdmp

It is the file that ends up installed: /usr/lib/emacs/31.0.50/x86_64-
pc-linux-gnu/emacs-
e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5.pdmp.

> If it is identical, are you sure you are invoking the correct 'emacs'
> executable?

I am invoking Emacs globally, i.e. just `emacs`. I install newly built
Emacs, then I try calling `emacs -Q`, I get the error, and then I
install the older Emacs build I was using previously and which works.

>   How many Emacs executables do you have in the $pkgdir/bin
> directory (from where you supposedly invoke Emacs), and what are
> their names?

    λ ls ./pkg/emacs-git/usr/bin/
    ebrowse  emacs  emacs-31.0.50  emacsclient  etags.emacs  nemacs
    λ pacman -Ql emacs-git | grep usr/bin/
    emacs-git /usr/bin/
    emacs-git /usr/bin/ebrowse
    emacs-git /usr/bin/emacs
    emacs-git /usr/bin/emacs-31.0.50
    emacs-git /usr/bin/emacsclient
    emacs-git /usr/bin/etags.emacs
    emacs-git /usr/bin/nemacs

Btw, since you asked, I also just of thought of trying to invoke
`./pkg/emacs-git/usr/bin/emacs -Q` rather than the global emacs. It ends up
printing same output.

> > This is same location as for the "working" Emacs build:
>
> What is the "working" Emacs build, and how is it different from the
> one that doesn't work?

They're just assembled from different commits, I looked at the files
list and it's the same, barring the difference in hash names in some
files.

Actually, it turns out that assembling from the older commit fails as
well now. I will try tomorrow to remove whole build directory
completely and re-clone everything from scratch.

> > > If you run Emacs from the src directory of the build tree, does
> > > it
> > > work?
> >
> > Yes, if I run it as `./build/src/emacs -Q`, it does work.
>
> Is the contents of the emacs.pdmp file in the source directory
> identical to the contents of
> /usr/lib/emacs/31.0.50/x86_64-pc-linux-gnu/emacs-
> e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5.pdmp
> ?

Yes:

    λ md5sum ./pkg/emacs-git/usr/lib/emacs/31.0.50/x86_64-pc-linux-gnu/emacs-e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5.pdmp /usr/lib/emacs/31.0.50/x86_64-pc-linux-gnu/emacs-e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5.pdmp
    36511c7936b906a2f8719e9eea6401c2  ./pkg/emacs-git/usr/lib/emacs/31.0.50/x86_64-pc-linux-gnu/emacs-e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5.pdmp
    36511c7936b906a2f8719e9eea6401c2  /usr/lib/emacs/31.0.50/x86_64-pc-linux-gnu/emacs-e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5.pdmp

Message #38 received at 77727 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
Cc: casouri <at> gmail.com, 77727 <at> debbugs.gnu.org
Subject: Re: bug#77727: [PATCH] Limit rust-ts-specific comment-start check
 to rust-ts (bug#77727)
Date: Fri, 18 Apr 2025 08:57:41 +0300

> From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
> Cc: casouri <at> gmail.com, 77727 <at> debbugs.gnu.org
> Date: Thu, 17 Apr 2025 21:12:19 +0300
> 
> > > Yes, it's being run as `make DESTDIR="$pkgdir/" install`
> >
> > What is the value of $pkgdir ?
> 
> It's /home/constantine/Projects/builds/emacs-git/pkg/emacs-git/

If that's so, then why is the .pdmp file installed under /usr/lib/ and
not under $pkgdir?  You said:

> > > Okay, so I just tried doing a `find -type f -name "*.pdmp" -
> > > delete`,
> > > and then rebuilding Emacs (to make sure no pdmp files are stale),
> > > then
> > > assembled/installed package. I see the file ends up is at
> > >
> > > /usr/lib/emacs/31.0.50/x86_64-pc-linux-gnu/emacs-
> > > e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5.pd
> > > mp

This is not under $pkgdir.  And the /usr/lib/ part is incorrect: it
should be under libexec/ instead.  Or did you configure $libexecdir to
be in /usr/lib/ for some reason?  (That's not the default.)

Do you have a directory named like this:

  /home/constantine/Projects/builds/emacs-git/pkg/emacs-git/usr/libexec/emacs/31.0.50/x86_64-pc-linux-gnu/

and if you do, do you see a .pdmp file of the above name there?

> > Is the fingerprint in your case identical to the name of the .pdmp
> > file (sans the extension)?
> 
> Yes. I just rebuilt while saving the output, and there are 3
> fingerprints mentioning lines:
> 
> Dumping fingerprint: e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5
> Dumping fingerprint: e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5
> /usr/bin/install -c -m 644 src/emacs.pdmp "/home/constantine/Projects/builds/emacs-git/pkg/emacs-git//usr/lib/emacs/31.0.50/x86_64-pc-linux-gnu"/emacs-`./src/emacs --fingerprint`.pdmp
> 
> It is the file that ends up installed: /usr/lib/emacs/31.0.50/x86_64-
> pc-linux-gnu/emacs-
> e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5.pdmp.

But note that the directory is incorrect: the "/usr/bin/install -c"
command correctly installs under $pkgdir, not in /usr/lib/emacs/.

> >   How many Emacs executables do you have in the $pkgdir/bin
> > directory (from where you supposedly invoke Emacs), and what are
> > their names?
> 
>     λ ls ./pkg/emacs-git/usr/bin/
>     ebrowse  emacs  emacs-31.0.50  emacsclient  etags.emacs  nemacs
>     λ pacman -Ql emacs-git | grep usr/bin/
>     emacs-git /usr/bin/
>     emacs-git /usr/bin/ebrowse
>     emacs-git /usr/bin/emacs
>     emacs-git /usr/bin/emacs-31.0.50
>     emacs-git /usr/bin/emacsclient
>     emacs-git /usr/bin/etags.emacs
>     emacs-git /usr/bin/nemacs

What does "ls -l" say about those executables?

> Btw, since you asked, I also just of thought of trying to invoke
> `./pkg/emacs-git/usr/bin/emacs -Q` rather than the global emacs. It ends up
> printing same output.

Anyway, I don't quite understand what happens (too many custom scripts
and variables are involved), but it looks like you have a botched
configuration of how Emacs is installed for some reason.  You need to
sort that out, I think.  I believe others are using installed Emacs 31
with no problems, so it's something local on your system.

Message #41 received at 77727 <at> debbugs.gnu.org (full text, mbox):

From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: casouri <at> gmail.com, 77727 <at> debbugs.gnu.org
Subject: Re: bug#77727: [PATCH] Limit rust-ts-specific comment-start check
 to rust-ts (bug#77727)
Date: Fri, 18 Apr 2025 12:48:03 +0300

Anyway, to avoid keep guessing I did a series of experiments.

I first found that recloning everything anew fixes the problem.

I kept the older problematic repo, so at that point I tried:

1. Removing `build` dir
2. Removing everything untracked under `lisp/` (with `git clean -fdx --
lisp`).
3. Removing the DESTDIR, i.e. recreating it anew before installation.

Neither helped.

At that point I tried a `git clean -fdx -- .` to remove everything
untracked from Emacs repo. That did help.

So at that point it is clear the reason for the break is some stray
artifact not being removed, not even by `make boostrap`.

I created a list of files before and after (with `git status
--ignored`), and the difference is only the removed files (no added
ones) as shown below.

I don't really see how any of them could be causing it, but… well,
these are the findings.

    15d13
    <       Makefile
    17d14
    <       admin/charsets/Makefile
    20,21d16
    <       admin/grammars/Makefile
    <       admin/unidata/Makefile
    192,193d186
    <       config.log
    <       config.status
    195,197d187
    <       configure~
    <       cross/Makefile
    <       doc/emacs/Makefile
    199,200d188
    <       doc/lispintro/Makefile
    <       doc/lispref/Makefile
    202d189
    <       doc/misc/Makefile
    341d327
    <       exec/config.h.in~
    344d329
    <       exec/configure~
    347,353d331
    <       java/AndroidManifest.xml
    <       java/Makefile
    <       leim/Makefile
    <       leim/small-ja-dic-option
    <       lib-src/Makefile
    <       lib/Makefile
    <       lib/gnulib.mk
    2055,2060d2032
    <       lwlib/Makefile
    <       nextstep/Makefile
    <       nt/Makefile
    <       oldXMenu/Makefile
    <       src/Makefile
    <       src/config.h
    2062,2068d2033
    <       src/config.in~
    <       src/emacs-module.h
    <       src/epaths.h
    <       src/verbose.mk
    <       test/Makefile
    <       test/infra/Makefile
    <       test/manual/noverlay/Makefile

---------

To answer your question: `./configure` call I'm using does modify some
installation directories, but I'm sure it's unrelated to the problem,
because these "modifications" worked before and work now that I
removed build artifacts.

Message #44 received at 77727 <at> debbugs.gnu.org (full text, mbox):

From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 77727 <at> debbugs.gnu.org
Subject: Re: [PATCH] Limit rust-ts-specific comment-start check to rust-ts
 (bug#77727)
Date: Fri, 18 Apr 2025 12:48:27 +0300

On Wed, 2025-04-16 at 22:58 -0700, Yuan Fu wrote:
> 
> 
> > On Apr 11, 2025, at 4:51 AM, Konstantin Kharlamov
> > <Hi-Angel <at> yandex.ru> 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.

Message #49 received at 77727-done <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
Cc: 77727-done <at> debbugs.gnu.org
Subject: Re: [PATCH] Limit rust-ts-specific comment-start check to rust-ts
 (bug#77727)
Date: Fri, 18 Apr 2025 16:35:13 -0700

> On Apr 18, 2025, at 2:48 AM, Konstantin Kharlamov <Hi-Angel <at> yandex.ru> wrote:
> 
> On Wed, 2025-04-16 at 22:58 -0700, Yuan Fu wrote:
>> 
>> 
>>> On Apr 11, 2025, at 4:51 AM, Konstantin Kharlamov
>>> <Hi-Angel <at> yandex.ru> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.