GNU bug report logs -
#41649
27.0.91; beginning-of-defun doesn't work inside React markup in js-jsx-mode
Previous Next
Reported by: Brian Leung <bkleung89 <at> gmail.com>
Date: Mon, 1 Jun 2020 18:01:01 UTC
Severity: normal
Found in version 27.0.91
Done: Alan Mackenzie <acm <at> muc.de>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 41649 in the body.
You can then email your comments to 41649 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41649
; Package
emacs
.
(Mon, 01 Jun 2020 18:01:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Brian Leung <bkleung89 <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 01 Jun 2020 18:01:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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)
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41649
; Package
emacs
.
(Tue, 02 Jun 2020 17:13:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 41649 <at> debbugs.gnu.org (full text, mbox):
Hello Brian.
In article <mailman.928.1591034465.2541.bug-gnu-emacs <at> 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).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41649
; Package
emacs
.
(Tue, 02 Jun 2020 17:29:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 41649 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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 <at> muc.de> wrote:
> Hello Brian.
>
> In article <mailman.928.1591034465.2541.bug-gnu-emacs <at> 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).
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41649
; Package
emacs
.
(Tue, 02 Jun 2020 21:44:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 41649 <at> debbugs.gnu.org (full text, mbox):
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. :-)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41649
; Package
emacs
.
(Tue, 02 Jun 2020 21:46:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 41649 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41649
; Package
emacs
.
(Wed, 03 Jun 2020 19:40:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 41649 <at> debbugs.gnu.org (full text, mbox):
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).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41649
; Package
emacs
.
(Wed, 03 Jun 2020 20:09:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 41649 <at> debbugs.gnu.org (full text, mbox):
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!
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41649
; Package
emacs
.
(Thu, 04 Jun 2020 16:24:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 41649 <at> debbugs.gnu.org (full text, mbox):
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).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41649
; Package
emacs
.
(Thu, 04 Jun 2020 16:27:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 41649 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41649
; Package
emacs
.
(Thu, 04 Jun 2020 16:42:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 41649 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
It works for me also. Thanks.
On Thu, Jun 4, 2020 at 9:26 AM Dmitry Gutov <dgutov <at> 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.
>
[Message part 2 (text/html, inline)]
Reply sent
to
Alan Mackenzie <acm <at> muc.de>
:
You have taken responsibility.
(Sun, 07 Jun 2020 15:24:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Brian Leung <bkleung89 <at> gmail.com>
:
bug acknowledged by developer.
(Sun, 07 Jun 2020 15:24:01 GMT)
Full text and
rfc822 format available.
Message #37 received at 41649-done <at> debbugs.gnu.org (full text, mbox):
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 <at> 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).
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 06 Jul 2020 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 265 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.