GNU bug report logs -
#77727
tsx-ts-mode: fill-paragraph doesn't work for doc-comments
Previous Next
Full log
Message #20 received at 77727 <at> debbugs.gnu.org (full text, mbox):
> 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.
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.