GNU bug report logs -
#47488
Treatment of # in js.el
Previous Next
Reported by: Reuben Thomas <rrt <at> sc3d.org>
Date: Mon, 29 Mar 2021 21:29:02 UTC
Severity: minor
Tags: fixed
Fixed in version 28.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
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 47488 in the body.
You can then email your comments to 47488 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#47488
; Package
emacs
.
(Mon, 29 Mar 2021 21:29:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Reuben Thomas <rrt <at> sc3d.org>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 29 Mar 2021 21:29: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)]
I started using private class fields, as described here
<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Private_class_fields>
(a stage 3 proposal that is widely implemented, though not actually
standardized yet AFAICT).
These are normal fields that start with a hash.
I find in js--proper-indentation the line (annotated by git blame):
17b5d0f7077 (Chong Yidong 2009-08-14 2864) ((eq
(char-after) ?#) 0)
It sets the indentation for a line starting with # unconditionally to 0. I
cannot find any other use of # in JavaScript that would justify treating
lines starting with # apparently like C preprocessor macros. There is other
related code, and it all seems to go back to when js.el was first installed
in Emacs.
Is this just because the code was originally based on cc-mode or something,
and the references to hash were never removed? Or was cpp used with early
JavaScript?? I see references such as js--opt-cpp-start which says "Regexp
matching the prefix of a cpp directive", and a match for "#define" in
js--update-quick-match-re.
I cannot see any code in js-tests.el that tests this cpp-related
functionality.
Is there some reason to keep the cpp-related code in js.el? I presume
removing it would simplify then adding support for private class fields;
indeed, maybe no particular support is needed if cpp support is first
removed.
--
https://rrt.sc3d.org
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47488
; Package
emacs
.
(Tue, 30 Mar 2021 00:51:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 47488 <at> debbugs.gnu.org (full text, mbox):
On 30.03.2021 00:28, Reuben Thomas via Bug reports for GNU Emacs, the
Swiss army knife of text editors wrote:
> Is this just because the code was originally based on cc-mode or
> something, and the references to hash were never removed? Or was cpp
> used with early JavaScript?? I see references such as js--opt-cpp-start
> which says "Regexp matching the prefix of a cpp directive", and a match
> for "#define" in js--update-quick-match-re.
IIRC this was related to the use of the C preprocessor in some JS
codebases (Mozilla?). Not sure if that practice stopped.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47488
; Package
emacs
.
(Sat, 08 May 2021 12:44:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 47488 <at> debbugs.gnu.org (full text, mbox):
Reuben Thomas <rrt <at> sc3d.org> writes:
> I started using private class fields, as described here (a stage 3 proposal that is
> widely implemented, though not actually standardized yet AFAICT).
>
> These are normal fields that start with a hash.
>
> I find in js--proper-indentation the line (annotated by git blame):
>
> 17b5d0f7077 (Chong Yidong 2009-08-14 2864) ((eq (char-after) ?#) 0)
Yeah, that doesn't seem correct for Javascript. I've just removed that
line in Emacs 28, and that seems to fix the issue for me.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) fixed.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 08 May 2021 12:44:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 28.1, send any further explanations to
47488 <at> debbugs.gnu.org and Reuben Thomas <rrt <at> sc3d.org>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 08 May 2021 12:44:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47488
; Package
emacs
.
(Sun, 09 May 2021 11:19:02 GMT)
Full text and
rfc822 format available.
Message #18 received at 47488 <at> debbugs.gnu.org (full text, mbox):
On 08.05.2021 15:43, Lars Ingebrigtsen wrote:
> Yeah, that doesn't seem correct for Javascript. I've just removed that
> line in Emacs 28, and that seems to fix the issue for me.
I have just done a search, and there are still a fair number of lines like
#ifdef XP_UNIX
#ifndef XP_MACOSX
#define UNIX_BUT_NOT_MAC
#endif
#endif
...
#ifdef UNIX_BUT_NOT_MAC
pref("general.autoScroll", false);
#else
pref("general.autoScroll", true);
#endif
in JS files in gecko-dev.
(The above is from browser/app/profile/firefox.js).
And they also have pieces like this.#m?.x; (mostly in test examples).
So ideally we would support both.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47488
; Package
emacs
.
(Sun, 09 May 2021 11:33:01 GMT)
Full text and
rfc822 format available.
Message #21 received at 47488 <at> debbugs.gnu.org (full text, mbox):
On 09.05.2021 14:18, Dmitry Gutov wrote:
> So ideally we would support both.
Also see js--beginning-of-macro which is still called in
js--proper-indentation.
It is a part of the same feature.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47488
; Package
emacs
.
(Mon, 10 May 2021 08:30:02 GMT)
Full text and
rfc822 format available.
Message #24 received at 47488 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> So ideally we would support both.
Hm, yes I guess so. But how?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47488
; Package
emacs
.
(Mon, 10 May 2021 08:35:02 GMT)
Full text and
rfc822 format available.
Message #27 received at 47488 <at> debbugs.gnu.org (full text, mbox):
On Sun, 9 May 2021 at 12:18, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>
> So ideally we would support both.
Thanks for doing the research, Dmitry!
Sorry not to be more useful here, but one suggestion: I doubt there
are many code bases that use the hash character in both senses, so if
there were a solution that allowed both to be supported but not at the
same time, that would already be a big improvement on the current
situation. (My impression is that using cpp with JavaScript is very
much a legacy technique.)
--
https://rrt.sc3d.org
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47488
; Package
emacs
.
(Mon, 10 May 2021 12:13:02 GMT)
Full text and
rfc822 format available.
Message #30 received at 47488 <at> debbugs.gnu.org (full text, mbox):
On 10.05.2021 11:29, Lars Ingebrigtsen wrote:
> Hm, yes I guess so. But how?
Maybe check against a specific list of preprocessor instructions, such
as #define, #ifdef, etc.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47488
; Package
emacs
.
(Mon, 10 May 2021 12:15:02 GMT)
Full text and
rfc822 format available.
Message #33 received at 47488 <at> debbugs.gnu.org (full text, mbox):
On 10.05.2021 11:34, Reuben Thomas via Bug reports for GNU Emacs, the
Swiss army knife of text editors wrote:
> Sorry not to be more useful here, but one suggestion: I doubt there
> are many code bases that use the hash character in both senses, so if
> there were a solution that allowed both to be supported but not at the
> same time, that would already be a big improvement on the current
> situation. (My impression is that using cpp with JavaScript is very
> much a legacy technique.)
Well, Mozilla codebase is the one that does both (and I doubt there are
many other examples of using C preprocessor in JS).
We could add a custom var that disables this behavior, of course.
js2-mode has one, but it only affects the parser, not the indentation
behavior.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47488
; Package
emacs
.
(Tue, 11 May 2021 12:22:01 GMT)
Full text and
rfc822 format available.
Message #36 received at 47488 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> We could add a custom var that disables this behavior, of
> course. js2-mode has one, but it only affects the parser, not the
> indentation behavior.
If we could avoid having a user option, that's be nice...
> Maybe check against a specific list of preprocessor instructions, such
> as #define, #ifdef, etc.
I think that sounds like a good solution. Grepping around a bit,
perhaps `cpp-font-lock-keywords-source-directives' in font-lock.el would
be a good source to use here?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug No longer marked as fixed in versions 28.1 and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 11 May 2021 12:23:02 GMT)
Full text and
rfc822 format available.
Removed tag(s) fixed.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Tue, 11 May 2021 12:23:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47488
; Package
emacs
.
(Tue, 11 May 2021 12:46:01 GMT)
Full text and
rfc822 format available.
Message #43 received at 47488 <at> debbugs.gnu.org (full text, mbox):
On 11.05.2021 15:21, Lars Ingebrigtsen wrote:
> Dmitry Gutov <dgutov <at> yandex.ru> writes:
>
>> We could add a custom var that disables this behavior, of
>> course. js2-mode has one, but it only affects the parser, not the
>> indentation behavior.
>
> If we could avoid having a user option, that's be nice...
Probably not without seeing an occasional false positive, e.g. ...
>> Maybe check against a specific list of preprocessor instructions, such
>> as #define, #ifdef, etc.
>
> I think that sounds like a good solution. Grepping around a bit,
> perhaps `cpp-font-lock-keywords-source-directives' in font-lock.el would
> be a good source to use here?
... looking at the regexp it also matches #file, #line or #warning.
Each of these could also be a name of a private attribute, I think.
Still, if those are indeed standard preprocessor directives, this var
looks like a good choice.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47488
; Package
emacs
.
(Wed, 12 May 2021 13:33:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 47488 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
>> I think that sounds like a good solution. Grepping around a bit,
>> perhaps `cpp-font-lock-keywords-source-directives' in font-lock.el would
>> be a good source to use here?
>
> ... looking at the regexp it also matches #file, #line or #warning.
>
> Each of these could also be a name of a private attribute, I
> think. Still, if those are indeed standard preprocessor directives,
> this var looks like a good choice.
I've never heard of the #file directive, but:
;; `cpp-font-lock-keywords-source-directives' is calculated from:
;;
;; (regexp-opt
;; '("define" "elif" "else" "endif" "error" "file" "if" "ifdef"
;; "ifndef" "import" "include" "line" "pragma" "undef" "warning"))
I spent 30 seconds googling, and I could find no list of directive that
includes #file, so... Bug #warning is used, and so is #line, so perhaps
it's an old thing?
Anyway, I'll amend the change to js.el to check whether it matches this
regexp.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) fixed.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Wed, 12 May 2021 13:42:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 28.1, send any further explanations to
47488 <at> debbugs.gnu.org and Reuben Thomas <rrt <at> sc3d.org>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Wed, 12 May 2021 13:42:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47488
; Package
emacs
.
(Wed, 12 May 2021 13:54:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 47488 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Wed, 12 May 2021 15:32:01 +0200
> Cc: 47488 <at> debbugs.gnu.org, Reuben Thomas <rrt <at> sc3d.org>
>
> I've never heard of the #file directive, but:
>
> ;; `cpp-font-lock-keywords-source-directives' is calculated from:
> ;;
> ;; (regexp-opt
> ;; '("define" "elif" "else" "endif" "error" "file" "if" "ifdef"
> ;; "ifndef" "import" "include" "line" "pragma" "undef" "warning"))
>
> I spent 30 seconds googling, and I could find no list of directive that
> includes #file, so... Bug #warning is used, and so is #line, so perhaps
> it's an old thing?
The #file directive is emitted by the preprocessor, so that later
compiling the preprocessed source would yield the correct source line
numbers. Try preprocessing some .c file with "gcc -E" and you will
see these directives in the output.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47488
; Package
emacs
.
(Wed, 12 May 2021 13:57:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 47488 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> The #file directive is emitted by the preprocessor, so that later
> compiling the preprocessed source would yield the correct source line
> numbers. Try preprocessing some .c file with "gcc -E" and you will
> see these directives in the output.
Ah; thanks.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47488
; Package
emacs
.
(Wed, 12 May 2021 14:40:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 47488 <at> debbugs.gnu.org (full text, mbox):
On Mai 12 2021, Eli Zaretskii wrote:
> The #file directive is emitted by the preprocessor, so that later
> compiling the preprocessed source would yield the correct source line
> numbers. Try preprocessing some .c file with "gcc -E" and you will
> see these directives in the output.
Not by gcc. It uses # LINE FILE FLAGS for that purpose. The gcc
preprocessor doesn't know anything about #file.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47488
; Package
emacs
.
(Wed, 12 May 2021 14:50:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 47488 <at> debbugs.gnu.org (full text, mbox):
> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 47488 <at> debbugs.gnu.org,
> dgutov <at> yandex.ru, rrt <at> sc3d.org
> Date: Wed, 12 May 2021 16:39:13 +0200
>
> On Mai 12 2021, Eli Zaretskii wrote:
>
> > The #file directive is emitted by the preprocessor, so that later
> > compiling the preprocessed source would yield the correct source line
> > numbers. Try preprocessing some .c file with "gcc -E" and you will
> > see these directives in the output.
>
> Not by gcc. It uses # LINE FILE FLAGS for that purpose. The gcc
> preprocessor doesn't know anything about #file.
You are right, sorry. I confused this with #line, which can
optionally state the file.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47488
; Package
emacs
.
(Wed, 12 May 2021 14:57:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 47488 <at> debbugs.gnu.org (full text, mbox):
On 12.05.2021 16:32, Lars Ingebrigtsen wrote:
> Anyway, I'll amend the change to js.el to check whether it matches this
> regexp.
Thanks!
We'll probably need to add a user option anyway, but that can wait until
the corresponding bug report.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 10 Jun 2021 11:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 115 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.