bug#7882: 24.0.50; Bad regexp for javascript regexps

bug#7882: 24.0.50; Bad regexp for javascript regexps

[Harald Hanche-Olsen]

Put the following four line code snippet in a new buffer:

replace(/\\/g,something);
// Now we're in trouble:
// Still in trouble.
// And all's well again.

and activate js-mode and font-lock-mode.

The syntax colouring is now off: The code starting with the first
slash on the first line and ending with the first slash on the second
line is coloured as a regexp; now the syntax highlighter is unaware
that we are in a comment, and reads the single quote as the start of a
string. After the second single quote things return to normal.

The problem seems to lie with the constant js--regexp-literal declared
in js.el, as this regexp does not treat backslashes with sufficient care.

In GNU Emacs 24.0.50.1 (x86_64-apple-darwin10.5.0, NS apple-appkit-1038.35)
 of 2010-12-27 on mack
Windowing system distributor `Apple', version 10.3.1038
configured using `configure  '--with-ns''

- Harald

bug#7882: 24.0.50; Bad regexp for javascript regexps

[Stefan Monnier]

> replace(/\\/g,something);

Thanks, I've installed the patch below into the emacs-23 branch which
should fix this problem.  The highlighting is not reliable when the
regexp spans multiple lines, tho, so I wonder: are multi-line regexps
valid? common? important?


        Stefan

bug#7882: closed

[Harald Hanche-Olsen]

I have no idea how common or important multiline regexps are in
javascript. As far as I am concerned, if it's difficult to match them
reliably, maybe one shouldn't even try. Though that has its own
dangers: Namely, stuff inside an unmatched regexp triggering
inappropriate syntax highlighting. So perhaps we should stick with
doing the best we can, anyhow.

- Harald