GNU bug report logs - #47488
Treatment of # in js.el

Previous Next

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.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: bug-emacs <bug-emacs <at> gnu.org>
Subject: Treatment of # in js.el
Date: Mon, 29 Mar 2021 21:28:29 +0000

[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)]

Message #8 received at 47488 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Reuben Thomas <rrt <at> sc3d.org>, 47488 <at> debbugs.gnu.org
Subject: Re: bug#47488: Treatment of # in js.el
Date: Tue, 30 Mar 2021 03:50:09 +0300

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.

Message #11 received at 47488 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 47488 <at> debbugs.gnu.org
Subject: Re: bug#47488: Treatment of # in js.el
Date: Sat, 08 May 2021 14:43:29 +0200

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

Message #18 received at 47488 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Reuben Thomas <rrt <at> sc3d.org>
Cc: 47488 <at> debbugs.gnu.org
Subject: Re: bug#47488: Treatment of # in js.el
Date: Sun, 9 May 2021 14:18:03 +0300

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.

Message #21 received at 47488 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Reuben Thomas <rrt <at> sc3d.org>
Cc: 47488 <at> debbugs.gnu.org
Subject: Re: bug#47488: Treatment of # in js.el
Date: Sun, 9 May 2021 14:31:56 +0300

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.

Message #24 received at 47488 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 47488 <at> debbugs.gnu.org, Reuben Thomas <rrt <at> sc3d.org>
Subject: Re: bug#47488: Treatment of # in js.el
Date: Mon, 10 May 2021 10:29:14 +0200

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

Message #27 received at 47488 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 47488 <at> debbugs.gnu.org
Subject: Re: bug#47488: Treatment of # in js.el
Date: Mon, 10 May 2021 09:34:04 +0100

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

Message #30 received at 47488 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 47488 <at> debbugs.gnu.org, Reuben Thomas <rrt <at> sc3d.org>
Subject: Re: bug#47488: Treatment of # in js.el
Date: Mon, 10 May 2021 15:12:30 +0300

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.

Message #33 received at 47488 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 47488 <at> debbugs.gnu.org
Subject: Re: bug#47488: Treatment of # in js.el
Date: Mon, 10 May 2021 15:14:11 +0300

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.

Message #36 received at 47488 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 47488 <at> debbugs.gnu.org, Reuben Thomas <rrt <at> sc3d.org>
Subject: Re: bug#47488: Treatment of # in js.el
Date: Tue, 11 May 2021 14:21:45 +0200

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

Message #43 received at 47488 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 47488 <at> debbugs.gnu.org, Reuben Thomas <rrt <at> sc3d.org>
Subject: Re: bug#47488: Treatment of # in js.el
Date: Tue, 11 May 2021 15:45:13 +0300

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.

Message #46 received at 47488 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 47488 <at> debbugs.gnu.org, Reuben Thomas <rrt <at> sc3d.org>
Subject: Re: bug#47488: Treatment of # in js.el
Date: Wed, 12 May 2021 15:32:01 +0200

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

Message #53 received at 47488 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 47488 <at> debbugs.gnu.org, rrt <at> sc3d.org, dgutov <at> yandex.ru
Subject: Re: bug#47488: Treatment of # in js.el
Date: Wed, 12 May 2021 16:53:21 +0300

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

Message #56 received at 47488 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 47488 <at> debbugs.gnu.org, rrt <at> sc3d.org, dgutov <at> yandex.ru
Subject: Re: bug#47488: Treatment of # in js.el
Date: Wed, 12 May 2021 15:56:05 +0200

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

Message #59 received at 47488 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, rrt <at> sc3d.org, 47488 <at> debbugs.gnu.org,
 dgutov <at> yandex.ru
Subject: Re: bug#47488: Treatment of # in js.el
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.

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

Message #62 received at 47488 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: larsi <at> gnus.org, rrt <at> sc3d.org, 47488 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#47488: Treatment of # in js.el
Date: Wed, 12 May 2021 17:49:13 +0300

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

Message #65 received at 47488 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 47488 <at> debbugs.gnu.org, Reuben Thomas <rrt <at> sc3d.org>
Subject: Re: bug#47488: Treatment of # in js.el
Date: Wed, 12 May 2021 17:56:45 +0300

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.