emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Emacs-bug-tracker] bug#7882: closed (24.0.50; Bad regexp for javascript


From: GNU bug Tracking System
Subject: [Emacs-bug-tracker] bug#7882: closed (24.0.50; Bad regexp for javascript regexps)
Date: Fri, 21 Jan 2011 20:43:02 +0000

Your message dated Fri, 21 Jan 2011 15:50:17 -0500
with message-id <address@hidden>
and subject line Re: bug#7882: 24.0.50; Bad regexp for javascript regexps
has caused the GNU bug report #7882,
regarding 24.0.50; Bad regexp for javascript regexps
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
7882: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7882
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 24.0.50; Bad regexp for javascript regexps Date: Fri, 21 Jan 2011 18:50:29 +0100 (CET)
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



--- End Message ---
--- Begin Message --- Subject: Re: bug#7882: 24.0.50; Bad regexp for javascript regexps Date: Fri, 21 Jan 2011 15:50:17 -0500 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)
> 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


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]