bug#41649: 27.0.91; beginning-of-defun doesn't work inside React markup in js-jsx-mode

[Brian Leung]

> Daniel, what is going on, here?  Is this just a simple coding error,
> where the second c-init-language-vars should have been removed at some

> stage?

I wasn't sure if js-beginning-of-defun was preferred here since it does not seem to detect ES2015 arrow functions like what is used here, whereas c-beginning-of-defun handles them fine outside of ReactJS cases: if you try M-: js-beginning-of-defun on my React example, point moves straight from the class declaration to the imports, which is not desirable. Should I file a separate ticket for that?

On Tue, Jun 2, 2020 at 10:12 AM Alan Mackenzie <acm@muc.de> wrote:

Hello Brian.

In article <mailman.928.1591034465.2541.bug-gnu-emacs@gnu.org> you wrote:
> [-- text/plain, encoding 7bit, charset: UTF-8, 44 lines --]

> With a file App.js that looks like:

> import * as React from "react";
> import { render } from "react-dom";

> const App = () => {
>   return (
>     <div>
>       <h1 id="abc">hello</h1>
>       <SearchParams />
>     </div>
>   );
> };

> render(<App />, document.getElementById("root"));


> If you open the file in JS mode (Emacs 27), and move point inside of
> "abc", calling

> M-: (c-beginning-of-defun)

That looks like a strange thing to do.  JS mode has its own
js-beginning-of-defun.

But wait - beginning-of-defun-function is set to c-beginning-of-defun,
which is probably why you reported the bug the way you did.

c-beginning-of-defun won't work, because a suitable member or derivative
of CC Mode hasn't been fully initialised.

> gives the following error:

> Debugger entered--Lisp error: (wrong-type-argument hash-table-p nil)
>   copy-hash-table(nil)
>   c-forward-<>-arglist(nil)
>   c-backward-<>-arglist(nil nil)
>   c-looking-at-decl-block(99 nil)
>   c-most-enclosing-decl-block((117 99 88 (40 . 50)))
>   c-widen-to-enclosing-decl-scope((117 99 88 (40 . 50)) 1 234)
>   c-beginning-of-defun()
>   eval((c-beginning-of-defun) t)
>   eval-_expression_((c-beginning-of-defun) nil nil 127)
>   funcall-interactively(eval-_expression_ (c-beginning-of-defun) nil nil 127)
>   call-interactively(eval-_expression_ nil nil)
>   command-execute(eval-_expression_)

> Manually invoking C-M-a inside the double quotes should end the same way.

It does.

The problem seems to stem from the top-level function #'js-mode.  Early
on, it invokes

    (c-init-language-vars js-mode)

, which initialises the CC Mode language variables to (mostly) their
Java Mode values.  js-mode continues by overwriting the local value of
quite a few of these variables, including beginning-of-defun-function.

js-mode then invokes

    (c-init-language-vars js-mode)

a second time, which initialises the language variables again, in
particular, those variables which just got a local value, including
beginning-of-defun-function.

Daniel, what is going on, here?  Is this just a simple coding error,
where the second c-init-language-vars should have been removed at some
stage?

> In GNU Emacs 27.0.91 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20)
> Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
> System Description: NixOS 20.09 (Nightingale)

--
Alan Mackenzie (Nuremberg, Germany).