all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#47488: Treatment of # in js.el
@ 2021-03-29 21:28 Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-03-30  0:50 ` Dmitry Gutov
  2021-05-08 12:43 ` Lars Ingebrigtsen
  0 siblings, 2 replies; 17+ messages in thread
From: Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-03-29 21:28 UTC (permalink / raw)
  To: 47488

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#47488: Treatment of # in js.el
  2021-03-29 21:28 bug#47488: Treatment of # in js.el Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-03-30  0:50 ` Dmitry Gutov
  2021-05-08 12:43 ` Lars Ingebrigtsen
  1 sibling, 0 replies; 17+ messages in thread
From: Dmitry Gutov @ 2021-03-30  0:50 UTC (permalink / raw)
  To: Reuben Thomas, 47488

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.





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#47488: Treatment of # in js.el
  2021-03-29 21:28 bug#47488: Treatment of # in js.el Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-03-30  0:50 ` Dmitry Gutov
@ 2021-05-08 12:43 ` Lars Ingebrigtsen
  2021-05-09 11:18   ` Dmitry Gutov
  1 sibling, 1 reply; 17+ messages in thread
From: Lars Ingebrigtsen @ 2021-05-08 12:43 UTC (permalink / raw)
  To: Reuben Thomas; +Cc: 47488

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#47488: Treatment of # in js.el
  2021-05-08 12:43 ` Lars Ingebrigtsen
@ 2021-05-09 11:18   ` Dmitry Gutov
  2021-05-09 11:31     ` Dmitry Gutov
                       ` (2 more replies)
  0 siblings, 3 replies; 17+ messages in thread
From: Dmitry Gutov @ 2021-05-09 11:18 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Reuben Thomas; +Cc: 47488

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.





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#47488: Treatment of # in js.el
  2021-05-09 11:18   ` Dmitry Gutov
@ 2021-05-09 11:31     ` Dmitry Gutov
  2021-05-10  8:29     ` Lars Ingebrigtsen
  2021-05-10  8:34     ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2 siblings, 0 replies; 17+ messages in thread
From: Dmitry Gutov @ 2021-05-09 11:31 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Reuben Thomas; +Cc: 47488

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.





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#47488: Treatment of # in js.el
  2021-05-09 11:18   ` Dmitry Gutov
  2021-05-09 11:31     ` Dmitry Gutov
@ 2021-05-10  8:29     ` Lars Ingebrigtsen
  2021-05-10 12:12       ` Dmitry Gutov
  2021-05-10  8:34     ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2 siblings, 1 reply; 17+ messages in thread
From: Lars Ingebrigtsen @ 2021-05-10  8:29 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: 47488, Reuben Thomas

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#47488: Treatment of # in js.el
  2021-05-09 11:18   ` Dmitry Gutov
  2021-05-09 11:31     ` Dmitry Gutov
  2021-05-10  8:29     ` Lars Ingebrigtsen
@ 2021-05-10  8:34     ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-05-10 12:14       ` Dmitry Gutov
  2 siblings, 1 reply; 17+ messages in thread
From: Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-05-10  8:34 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: Lars Ingebrigtsen, 47488

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#47488: Treatment of # in js.el
  2021-05-10  8:29     ` Lars Ingebrigtsen
@ 2021-05-10 12:12       ` Dmitry Gutov
  0 siblings, 0 replies; 17+ messages in thread
From: Dmitry Gutov @ 2021-05-10 12:12 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 47488, Reuben Thomas

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.





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#47488: Treatment of # in js.el
  2021-05-10  8:34     ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-05-10 12:14       ` Dmitry Gutov
  2021-05-11 12:21         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 17+ messages in thread
From: Dmitry Gutov @ 2021-05-10 12:14 UTC (permalink / raw)
  To: Reuben Thomas; +Cc: Lars Ingebrigtsen, 47488

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.





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#47488: Treatment of # in js.el
  2021-05-10 12:14       ` Dmitry Gutov
@ 2021-05-11 12:21         ` Lars Ingebrigtsen
  2021-05-11 12:45           ` Dmitry Gutov
  0 siblings, 1 reply; 17+ messages in thread
From: Lars Ingebrigtsen @ 2021-05-11 12:21 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: 47488, Reuben Thomas

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#47488: Treatment of # in js.el
  2021-05-11 12:21         ` Lars Ingebrigtsen
@ 2021-05-11 12:45           ` Dmitry Gutov
  2021-05-12 13:32             ` Lars Ingebrigtsen
  0 siblings, 1 reply; 17+ messages in thread
From: Dmitry Gutov @ 2021-05-11 12:45 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 47488, Reuben Thomas

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.





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#47488: Treatment of # in js.el
  2021-05-11 12:45           ` Dmitry Gutov
@ 2021-05-12 13:32             ` Lars Ingebrigtsen
  2021-05-12 13:53               ` Eli Zaretskii
  2021-05-12 14:56               ` Dmitry Gutov
  0 siblings, 2 replies; 17+ messages in thread
From: Lars Ingebrigtsen @ 2021-05-12 13:32 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: 47488, Reuben Thomas

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#47488: Treatment of # in js.el
  2021-05-12 13:32             ` Lars Ingebrigtsen
@ 2021-05-12 13:53               ` Eli Zaretskii
  2021-05-12 13:56                 ` Lars Ingebrigtsen
  2021-05-12 14:39                 ` Andreas Schwab
  2021-05-12 14:56               ` Dmitry Gutov
  1 sibling, 2 replies; 17+ messages in thread
From: Eli Zaretskii @ 2021-05-12 13:53 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 47488, dgutov, rrt

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#47488: Treatment of # in js.el
  2021-05-12 13:53               ` Eli Zaretskii
@ 2021-05-12 13:56                 ` Lars Ingebrigtsen
  2021-05-12 14:39                 ` Andreas Schwab
  1 sibling, 0 replies; 17+ messages in thread
From: Lars Ingebrigtsen @ 2021-05-12 13:56 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 47488, dgutov, rrt

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#47488: Treatment of # in js.el
  2021-05-12 13:53               ` Eli Zaretskii
  2021-05-12 13:56                 ` Lars Ingebrigtsen
@ 2021-05-12 14:39                 ` Andreas Schwab
  2021-05-12 14:49                   ` Eli Zaretskii
  1 sibling, 1 reply; 17+ messages in thread
From: Andreas Schwab @ 2021-05-12 14:39 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, dgutov, 47488, rrt

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#47488: Treatment of # in js.el
  2021-05-12 14:39                 ` Andreas Schwab
@ 2021-05-12 14:49                   ` Eli Zaretskii
  0 siblings, 0 replies; 17+ messages in thread
From: Eli Zaretskii @ 2021-05-12 14:49 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: larsi, dgutov, 47488, rrt

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#47488: Treatment of # in js.el
  2021-05-12 13:32             ` Lars Ingebrigtsen
  2021-05-12 13:53               ` Eli Zaretskii
@ 2021-05-12 14:56               ` Dmitry Gutov
  1 sibling, 0 replies; 17+ messages in thread
From: Dmitry Gutov @ 2021-05-12 14:56 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 47488, Reuben Thomas

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.





^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2021-05-12 14:56 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-03-29 21:28 bug#47488: Treatment of # in js.el Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-03-30  0:50 ` Dmitry Gutov
2021-05-08 12:43 ` Lars Ingebrigtsen
2021-05-09 11:18   ` Dmitry Gutov
2021-05-09 11:31     ` Dmitry Gutov
2021-05-10  8:29     ` Lars Ingebrigtsen
2021-05-10 12:12       ` Dmitry Gutov
2021-05-10  8:34     ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-05-10 12:14       ` Dmitry Gutov
2021-05-11 12:21         ` Lars Ingebrigtsen
2021-05-11 12:45           ` Dmitry Gutov
2021-05-12 13:32             ` Lars Ingebrigtsen
2021-05-12 13:53               ` Eli Zaretskii
2021-05-12 13:56                 ` Lars Ingebrigtsen
2021-05-12 14:39                 ` Andreas Schwab
2021-05-12 14:49                   ` Eli Zaretskii
2021-05-12 14:56               ` Dmitry Gutov

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.