bug#47488: Treatment of # in js.el

bug#47488: Treatment of # in js.el

[Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

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

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

bug#47488: Treatment of # in js.el

[Dmitry Gutov]

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.

bug#47488: Treatment of # in js.el

[Lars Ingebrigtsen]

Reuben Thomas <rrt@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

bug#47488: Treatment of # in js.el

[Dmitry Gutov]

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.

bug#47488: Treatment of # in js.el

[Dmitry Gutov]

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.

bug#47488: Treatment of # in js.el

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@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

bug#47488: Treatment of # in js.el

[Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Sun, 9 May 2021 at 12:18, Dmitry Gutov <dgutov@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

bug#47488: Treatment of # in js.el

[Dmitry Gutov]

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.

bug#47488: Treatment of # in js.el

[Dmitry Gutov]

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.

bug#47488: Treatment of # in js.el

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@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#47488: Treatment of # in js.el

[Dmitry Gutov]

On 11.05.2021 15:21, Lars Ingebrigtsen wrote:
> Dmitry Gutov <dgutov@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.

bug#47488: Treatment of # in js.el

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@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

bug#47488: Treatment of # in js.el

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 12 May 2021 15:32:01 +0200
> Cc: 47488@debbugs.gnu.org, Reuben Thomas <rrt@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.

bug#47488: Treatment of # in js.el

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

bug#47488: Treatment of # in js.el

[Andreas Schwab]

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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#47488: Treatment of # in js.el

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  47488@debbugs.gnu.org,
>   dgutov@yandex.ru,  rrt@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.

bug#47488: Treatment of # in js.el

[Dmitry Gutov]

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.