Perl mode screws up bad with this file. Cperl mode gets it better.
$ perl -c p.pl
p.pl syntax OK
$ cat p.pl
/this is a perl program to demonstrate emacs's wacky color biz/;
/this line is in the wrong color until here'/; #///
/this line is in the wrong color/;
#this comment turns back on emacs correct color: \b\b
/this line is in the right color/;
/but not this line until the end\/;/m;
$ emacs -Q p.pl
Anyway, one usually ends up having to stick in special comments with
some / ; ` ' etc. in them lest large tracts of code become the wrong
color. emacs-version "22.2.1"
So that's another attempt to exercise my super powers...
It turns out that 997, which had been merged with 26850, is actually a
different issue, and it is not fixed by the recent patch which
successfully dealt with Bug#26850 and Bug#26745 for Perl mode.
CPerl mode handles the examples correctly.
The issues are all related to each other because they all deal with the
difficulties to distinguish between a slash as a division sign and a
slash as a regex introduction. The apostrophe "'" is a red herring - it
increases the visibility of the bug, but isn't the root cause.
Right now, Perl mode tries to detect regexes based on what's before
them. Therefore, 26850 could be fixed by adding "return" to the stuff
which can occur before a regex. However, the examples in this bug
demonstrate regexes with *nothing* before them: Regular expressions can
start a statement just fine, they have a return value and set some
variables as side effects.
Correctly detecting "nothing" in a regex needs some care. So I'd like
to treat this as a separate bug which remains open for now.
> unmerge 997
> reopen 997
> So that's another attempt to exercise my super powers...
You have to send that text to [hidden email] in order for it to
take effect (generally if you do this as part of a public bug message,
you should use Bcc for that to avoid follow-ups from also going to
control; which is why you don't see that destination address when other
people do it).