bug#11014: cperl syntax highlighting breaking on certain complex regular expressions

bug#11014: cperl syntax highlighting breaking on certain complex regular expressions

[Nathan Trapuzzano]

Syntax highlighting in cperl-mode breaks for certain (or perhaps all)
complex regular expressions modified by /e and/or /x.

Here are 2 examples of offending code:

example 1 -----

sub greek_with_latin
{
    my ($self, $ref) = @_;
#     $self->{perseus_morph} = 0;
    $$ref =~ s/([^\&]*)([^\$]*)/
                                        my $gk = $1 || '';
                                        if ($gk)
                                        {
                                                $self->{perseus_morph} ? 
                                                  $self->perseus_handler(\$gk, 'grk') 
                                                : $self->{greek_handler}->(\$gk);
                                        }
                                        my $lt = $2 || '';
                                        if ($lt)
                                        {
                                                $self->{perseus_morph} ? 
                                                  $self->perseus_handler(\$lt, 'lat') 
                                                : $self->{latin_handler}->(\$lt);
                                        }
                                        $gk.$lt;
                                        /gex;
}

-----
example 2 -----

$$ref =~ s/'/$self->{ibycus4} ? '{\'}' : '\'\''/ge;

-----

Lines of code coming after "blocks" like these are all highlighted as
though they were quoted (at least that's what seems to be the case
judging from the color).

Running Arch build 23.4-1:

In GNU Emacs 23.4.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.9)
 of 2012-02-01 on shirley.hoetzel.info
configured using `configure  '--prefix=/usr' '--sysconfdir=/etc'
'--libexecdir=/usr/lib' '--localstatedir=/var' '--wit\ h-x-toolkit=gtk'
'--with-xft' 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe
-fstack-protector --param=ssp-buffer-size\ =4 -D_FORTIFY_SOURCE=2'
'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu''

bug#11014: cperl syntax highlighting breaking on certain complex regular expressions

[Stefan Monnier]

> Syntax highlighting in cperl-mode breaks for certain (or perhaps all)
> complex regular expressions modified by /e and/or /x.

I'm not familiar enough with cperl-mode's syntax fontification code to
help fix it, but FWIW, your second example works right in perl-mode, and
I've just fixed its code (with the patch below) so it also works right
on your first example.


        Stefan


=== modified file 'lisp/ChangeLog'
--- lisp/ChangeLog	2012-03-15 01:38:40 +0000
+++ lisp/ChangeLog	2012-03-15 03:09:10 +0000
@@ -1,5 +1,8 @@
 2012-03-15  Stefan Monnier  <monnier@iro.umontreal.ca>
 
+	* progmodes/perl-mode.el (perl-syntax-propertize-special-constructs):
+	Fix up parsing of multiline twoarg non-paired elements (bug#11014).
+
 	* imenu.el: Fix multiple inheritance breakage (bug#9199).
 	(imenu-add-to-menubar): Don't add a redundant index.
 	(imenu-update-menubar): Handle a dynamically composed keymap.

=== modified file 'lisp/progmodes/perl-mode.el'
--- lisp/progmodes/perl-mode.el	2012-01-19 07:21:25 +0000
+++ lisp/progmodes/perl-mode.el	2012-03-15 03:05:36 +0000
@@ -388,7 +388,11 @@
                       ;; In case of error, make sure we don't move backward.
 		      (scan-error (goto-char startpos) nil))
 		  (not (or (nth 8 (parse-partial-sexp
-				   (point) limit nil nil state 'syntax-table))
+				   ;; Since we don't know if point is within
+				   ;; the first or the scond arg, we have to
+				   ;; start from the beginning.
+				   (if twoargs (1+ (nth 8 state)) (point))
+				   limit nil nil state 'syntax-table))
 			   ;; If we have a self-paired opener and a twoargs
 			   ;; command, the form is s/../../ so we have to skip
 			   ;; a second time.

bug#11014: cperl syntax highlighting breaking on certain complex regular expressions

[Stefan Kangas]

Nathan Trapuzzano <nbtrap@nbtrap.com> writes:

> Syntax highlighting in cperl-mode breaks for certain (or perhaps all)
> complex regular expressions modified by /e and/or /x.
>
> Here are 2 examples of offending code:
>
> example 1 -----
>
> sub greek_with_latin
> {
>     my ($self, $ref) = @_;
> #     $self->{perseus_morph} = 0;
>     $$ref =~ s/([^\&]*)([^\$]*)/
>                                         my $gk = $1 || '';
>                                         if ($gk)
>                                         {
>                                                 $self->{perseus_morph} ? 
>                                                   $self->perseus_handler(\$gk, 'grk') 
>                                                 : $self->{greek_handler}->(\$gk);
>                                         }
>                                         my $lt = $2 || '';
>                                         if ($lt)
>                                         {
>                                                 $self->{perseus_morph} ? 
>                                                   $self->perseus_handler(\$lt, 'lat') 
>                                                 : $self->{latin_handler}->(\$lt);
>                                         }
>                                         $gk.$lt;
>                                         /gex;
> }
>
> -----
> example 2 -----
>
> $$ref =~ s/'/$self->{ibycus4} ? '{\'}' : '\'\''/ge;
>
> -----
>
> Lines of code coming after "blocks" like these are all highlighted as
> though they were quoted (at least that's what seems to be the case
> judging from the color).

I can't reproduce this on current master.  Are you still seeing this
on a modern version of Emacs?

If I don't hear back from you within a couple of weeks, Ill just close
this bug as unreproducible.

Best regards,
Stefan Kangas

bug#11014: cperl syntax highlighting breaking on certain complex regular expressions

[Stefan Kangas]

tags 11014 + unreproducible
close 11014
thanks

Stefan Kangas <stefan@marxist.se> writes:

> I can't reproduce this on current master.  Are you still seeing this
> on a modern version of Emacs?
>
> If I don't hear back from you within a couple of weeks, Ill just close
> this bug as unreproducible.

More information was requested, but none was given within 4 weeks, so
I'm closing this bug.  If this is still an issue, please reply to this
email (use "Reply to all" in your email client) and we can reopen the
bug report.

Best regards,
Stefan Kangas