unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Harald Jörg" <haj@posteo.de>
To: Stefan Kangas <stefankangas@gmail.com>, 16368@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	[thread overview]
Message-ID: <1dce9689-f0ae-e066-bbf0-fb92f9b997ce@posteo.de> (raw)
In-Reply-To: <CADwFkmm=7txZFvs8Ozg0y181DCbUUreV8ojhuQC6xpDw5ssjDQ@mail.gmail.com>

On 9/3/20 12:19 AM, Stefan Kangas wrote:
> Harald Jörg <haj@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@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






  reply	other threads:[~2020-09-02 23:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-06  1:28 bug#16368: 24.3; freeze in cperl mode when editing a regexp Vincent Lefevre
2019-09-20 23:33 ` Stefan Kangas
2020-09-02 20:06 ` bug#16368: [PATCH] cperl-mode: don't freeze over a cool regexp Harald Jörg
2020-09-02 22:19   ` Stefan Kangas
2020-09-02 23:40     ` Harald Jörg [this message]
2020-09-03  9:58       ` Stefan Kangas
2020-09-03 20:27         ` Harald Jörg
2020-09-03 21:12           ` Stefan Kangas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1dce9689-f0ae-e066-bbf0-fb92f9b997ce@posteo.de \
    --to=haj@posteo.de \
    --cc=16368@debbugs.gnu.org \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).