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

From: Eli Zaretskii <[email-masked]>
Date: Thu, 17 Apr 2025 10:37:56 +0300

> Cc: [email-masked]
> From: Konstantin Kharlamov <[email-masked]>
> 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
> > > <[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
> 
> 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.