GNU bug report logs - #16368
24.3; freeze in cperl mode when editing a regexp

Previous Next

Package: emacs;

Reported by: Vincent Lefevre <vincent <at> vinc17.net>

Date: Mon, 6 Jan 2014 01:30:02 UTC

Severity: normal

Tags: confirmed, patch

Found in versions 26.1, 24.3

Fixed in version 28.1

Done: Stefan Kangas <stefankangas <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Harald Jörg <haj <at> posteo.de>
To: Stefan Kangas <stefankangas <at> gmail.com>, 16368 <at> debbugs.gnu.org
Subject: bug#16368: [PATCH] cperl-mode: don't freeze over a cool regexp
Date: Thu, 3 Sep 2020 01:40:45 +0200
On 9/3/20 12:19 AM, Stefan Kangas wrote:
> Harald Jörg <haj <at> posteo.de> writes:
> 
>> Patch attached, including two test cases.
> 
> Thanks for working on cperl-mode bugs.
> 
> Testing the original recipe with your patch it is already an improvement
> in that it avoids the freeze.  But I see these messages:
> 
>   cperl-forward-group-in-re: error (scan-error Unbalanced parentheses 9 94)
>   (scan-error Unbalanced parentheses 9 94)
> 
> Is that the expected and desired behavior?

Yes, it is, sort of.  Maybe it should be fine-tuned.  At this point we
_have_ the situation of unbalanced parentheses, and cperl-mode rubs it
in for every character you type.

Just open a buffer in cperl-mode and start typing:

   $a =~ s/

At this point a message appears, with a different text when you open
a parentheses, and will haunt you until you get everything closed
properly.  Given that regexps can be messy and heavy with punctuation,
I'd say this is desired behavior.

I can only guess that the first part of the message (which starts with
"cperl-forward-group-in-re") was added out of frustration: The bug
prevented the second part of the message (without
"cperl-forward-group-in-re") from ever appearing.  Only this wasn't
fatal unless... there was this closing brace two characters before.
I'll check that, and prepare an updated patch if that's true.

> ---
> 
> Also, some minor nits:
> 
>> Subject: [PATCH] =?UTF-8?q?2020-09-02=20=20Harald=20J=C3=B6rg=20=20<haj <at> po?=
>>  =?UTF-8?q?steo.de>?=
> 
> Better first line:
> 
> Fix freeze in cperl-mode when editing a regexp
> 
>>  * lisp/progmodes/cperl-mode.el (cperl-forward-group-in-re): Make
>>  sure that an error is reported back to the caller (Bug#16368).
>>
>>  * test/lisp/progmodes/cperl-mode-tests.el (cperl-mode-test-bug-16368):
>>  Tests for balanced (no error) and unbalanced (caught exception)
>>  cases of `cperl-forward-group-in-re'.
> 
> Format these flush to the first column (no initial space).

No problem, I'll do so.  I thought I was supposed to create the commit
messages with C-x 4 a, but probably I misunderstood and should have
post-processed that text in the first place.

>> --- a/test/lisp/progmodes/cperl-mode-tests.el
>> +++ b/test/lisp/progmodes/cperl-mode-tests.el
> 
> I see this:
> 
>     ELC      lisp/progmodes/cperl-mode-tests.elc
> 
>   In end of data:
>   lisp/progmodes/cperl-mode-tests.el:73:1: Warning: the function
>       `cperl-forward-group-in-re' is not known to be defined.
> 
> You should add this line to the top:
> 
>   (require 'cperl-mode)

Hm. That should rather be _moving_ that line to the top?  The line is
there, in the test which calls this function.  For me this seemed to
be enough to avoid that message when byte-compiling.  But of course,
moving the line to the top is fine, probably more tests will follow
to exercise functions which aren't autoloaded.

Give me a few hours for a nap: It's past midnight here :)
-- 
Cheers,
haj





This bug report was last modified 4 years and 311 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.