bug#72296: 29.4; cperl-mode parsing error

[Eli Zaretskii]

> Cc: brian <me@briang.org>
> From: Harald Jörg <haj@posteo.de>
> Date: Thu, 25 Jul 2024 19:06:35 +0000
> 
> brian <me@briang.org> writes:
> 
> > I started emacs using 'emacs -Q /tmp/some-empty-file.pl' and activated
> > cperl mode by 'M-x cperl-mode'. I typed 'for (2..$n/2) {}' into the
> > empty buffer and as soon as I pressed '/' there was an error message in
> > the minibuffer
> >
> > End of ‘/ ... /’ string/RE not found: (scan-error Unbalanced
> > parentheses 11 38)
> >
> > and syntax hilighting was broken. Inserting a single space before '$'
> > cleared the error and fixed the hilighting.
> 
> I can reproduce this and am about to prepare a fix.
> 
> That code sits here since 1997, I find it rather surprising that it has
> not surfaced until now.  I'll run some tests and add a test case.  If I
> am not mistaken, then replacing a `progn` with `save-excursion` should
> do the trick:
> 
> index b85db699e72..34481925d3e 100644
> --- a/lisp/progmodes/cperl-mode.el
> +++ b/lisp/progmodes/cperl-mode.el
> @@ -4108,7 +4108,7 @@ cperl-find-pods-heres
>                                     (and (eq (preceding-char) ?\})
>                                          (cperl-after-block-p (point-min)))
>                                     (and (eq (char-syntax (preceding-char)) 
> ?w)
> -                                        (progn
> +                                        (save-excursion
>                                            (forward-sexp -1)
>  ;; After these keywords `/' starts a RE.  One should add all the
>  ;; functions/builtins which expect an argument, but ...
> 
> In newer versions the line numbers are different (~4650) but the issue
> is the same.  The unprotected (forward-sexp -1) skips over $n and the
> two characters before that are '..' which, in the following clause,
> makes the construct look like a flip-flop operator where '/' does start
> a regular expression.  Using 'save-excursion' undoes the skip before
> running the next checks.

Thanks, since this appears to be fixed on the emacs-30 branch, I'm
closing this bug.