GNU bug report logs -
#77727
tsx-ts-mode: fill-paragraph doesn't work for doc-comments
Previous Next
Full log
View this message in rfc822 format
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.
This bug report was last modified 31 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.