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

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

[Brian Leung]

[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]

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)

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.

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)

[-- Attachment #2: Type: text/html, Size: 1549 bytes --]

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

[Alan Mackenzie]

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).

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

[Brian Leung]

[-- Attachment #1: Type: text/plain, Size: 3334 bytes --]

> 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).
>
>

[-- Attachment #2: Type: text/html, Size: 4301 bytes --]

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

[Dmitry Gutov]

On 02.06.2020 20:27, Brian Leung wrote:
> 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?

A separate ticked is probably better.

The fix shouldn't be too hard, but there are a lot of "\\_<function" 
regexps to change or augment in there.

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

[Dmitry Gutov]

Hi Alan,

On 02.06.2020 20:12, Alan Mackenzie wrote:
> 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?

I agree that the second call should be removed.

You might be amused to look at the commit 4ad6c932a82, though, and see 
who the author is. :-)

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

[Alan Mackenzie]

Hello, Dmitry.

On Wed, Jun 03, 2020 at 00:43:32 +0300, Dmitry Gutov wrote:
> Hi Alan,

> On 02.06.2020 20:12, Alan Mackenzie wrote:
> > 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?

> I agree that the second call should be removed.

Thanks.

> You might be amused to look at the commit 4ad6c932a82, though, and see 
> who the author is. :-)

Indeed I am.  ;-)  It was me.  Funny thing is, I had absolutely no
recollection of ever modifying js.el, that is until I checked over my
notes from last November.

So, yes, It was just a simple coding error.  Apologies to Daniel for the
nuisance.

I'll get a patch onto the list as soon as I've got the time and energy to
check it over carefully.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Dmitry Gutov]

On 03.06.2020 22:39, Alan Mackenzie wrote:
> I'll get a patch onto the list as soon as I've got the time and energy to
> check it over carefully.

Thanks!

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

[Alan Mackenzie]

Hello, Dmitry and Brian.

On Wed, Jun 03, 2020 at 23:08:09 +0300, Dmitry Gutov wrote:
> On 03.06.2020 22:39, Alan Mackenzie wrote:
> > I'll get a patch onto the list as soon as I've got the time and energy to
> > check it over carefully.

> Thanks!

Would you please try out the following patch, which ought to fix the
problem the patch should fix.  Seeing as how it corrects the value of a
number of configuration variables (around fifteen), there might be
further incidental benefits.



diff --git a/lisp/progmodes/js.el b/lisp/progmodes/js.el
index 5ec3e94275..04b449ecd2 100644
--- a/lisp/progmodes/js.el
+++ b/lisp/progmodes/js.el
@@ -4591,7 +4591,6 @@ js-mode
   (setq imenu-create-index-function #'js--imenu-create-index)
 
   ;; for filling, pretend we're cc-mode
-  (c-init-language-vars js-mode)
   (setq-local comment-line-break-function #'c-indent-new-comment-line)
   (setq-local comment-multi-line t)
   (setq-local electric-indent-chars


It might well be too late to include this patch in the Emacs 27 release.
If you're reading this, Eli, what do you say?

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Dmitry Gutov]

On 04.06.2020 19:23, Alan Mackenzie wrote:
> Would you please try out the following patch, which ought to fix the
> problem the patch should fix.

I tried it a few days ago, and it indeed seemed to fix the reported 
scenario.

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

[Brian Leung]

[-- Attachment #1: Type: text/plain, Size: 340 bytes --]

It works for me also. Thanks.

On Thu, Jun 4, 2020 at 9:26 AM Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 04.06.2020 19:23, Alan Mackenzie wrote:
> > Would you please try out the following patch, which ought to fix the
> > problem the patch should fix.
>
> I tried it a few days ago, and it indeed seemed to fix the reported
> scenario.
>

[-- Attachment #2: Type: text/html, Size: 644 bytes --]

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

[Alan Mackenzie]

Hello, Brian and Dmitry.

On Thu, Jun 04, 2020 at 09:40:34 -0700, Brian Leung wrote:
> It works for me also. Thanks.

> On Thu, Jun 4, 2020 at 9:26 AM Dmitry Gutov <dgutov@yandex.ru> wrote:

> > On 04.06.2020 19:23, Alan Mackenzie wrote:
> > > Would you please try out the following patch, which ought to fix the
> > > problem the patch should fix.

> > I tried it a few days ago, and it indeed seemed to fix the reported
> > scenario.

OK, that's good, thanks.

Thinking about it, and considering how many js-mode settings get amended
by this patch, it is fairly complicated.  So, it really is too late for
the emacs-27 branch.  So I've committed the patch to master.

I'm closing the bug with this post.

-- 
Alan Mackenzie (Nuremberg, Germany).