bug#37127: 27.0.50; in cperl mode, scan-error Unbalanced parentheses

bug#37127: 27.0.50; in cperl mode, scan-error Unbalanced parentheses

[Vincent Lefevre]

On the following file

# -*- mode: cperl -*-
s/./(/e;

putting the cursor just after the opening parenthesis then typing a
closing parenthesis yields the following error:

  End of ‘s/ ... // ... /’ string/RE not found: (scan-error Unbalanced parentheses 26 29)

This follows

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33114#21


In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10)
 of 2019-08-20 built on cventin
Repository revision: 50dc4ca8d02a466a7236765edf83ae7cfb02d74c
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux bullseye/sid

Recent messages:
Loading /home/vlefevre/share/emacs/site-lisp/mutteditor.el (source)...done
Loading time...done
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --prefix=/usr/local/emacs-trunk'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS LIBSYSTEMD PDUMPER LCMS2
GMP

Important settings:
  value of $LC_COLLATE: POSIX
  value of $LC_CTYPE: en_US.UTF-8
  value of $LC_TIME: en_DK
  value of $LANG: POSIX
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  display-time-mode: t
  show-paren-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr warnings emacsbug message rmc puny dired
dired-loaddefs format-spec rfc822 mml easymenu mml-sec password-cache
epa derived epg epg-config gnus-util rmail rmail-loaddefs
text-property-search time-date subr-x seq byte-opt gv bytecomp
byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time cus-start cus-load paren cc-styles
cc-align cc-engine cc-vars cc-defs edmacro kmacro cl-loaddefs cl-lib
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 65536 8229)
 (symbols 48 8743 1)
 (strings 32 20748 2347)
 (string-bytes 1 700746)
 (vectors 16 11323)
 (vector-slots 8 144376 12556)
 (floats 8 24 26)
 (intervals 56 219 10)
 (buffers 992 12))

bug#37127: 27.0.50; in cperl mode, scan-error Unbalanced parentheses

[Stefan Kangas]

tags 37127 + confirmed
quit

Vincent Lefevre <vincent@vinc17.net> writes:

> On the following file
>
> # -*- mode: cperl -*-
> s/./(/e;
>
> putting the cursor just after the opening parenthesis then typing a
> closing parenthesis yields the following error:
>
>   End of ‘s/ ... // ... /’ string/RE not found: (scan-error Unbalanced parentheses 26 29)

I can reproduce this as well.

Best regards,
Stefan Kangas

bug#37127: [PATCH] cperl-mode: Suppress a misleading message

[Harald Jörg]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]

The unjustified message about a missing end of a RE is rather harmless,
it goes away after the next keystroke.  Nevertheless, this can be fixed.
It also happens in several related situations.

The message has its cause in the apparently totally unrelated function
'blink-matching-open'.  Whenever a closing paren is inserted, this
function highlights the corresponding opening paren for a short time.
As part of its processing, it narrows the buffer so that it ends with
the closing paren - thereby excluding the end of the regular expression.

In this state, it calls 'syntax-propertize', which in turn runs through
the cperl-mode functions for syntaxification, ending up eventually in
'cperl-forward-re' - which fails to find the end of the regular
expression in the narrowed buffer.

The patch suppresses the message if the following conditions are met:
   1) The buffer is currently narrowed
   2) We are at the end of the (narrowed) buffer
   3) The error in question is of type 'scan-error

The patch also contains a test to verify that the message isn't written
in the situation given in the bug report, and also that the message is
written if we do indeed have an unterminated regular expression.
--
Cheers,
haj

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Suppress a misleading message --]
[-- Type: text/x-diff, Size: 3065 bytes --]

From 85b8ccab3d5e43a4a3d4e622529248973b606a04 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Harald=20J=C3=B6rg?= <haj@posteo.de>
Date: Thu, 29 Oct 2020 21:03:12 +0100
Subject: [PATCH] ; Suppress a misleading message when closing a paren in a
 regex

* lisp/progmodes/cperl-mode.el (cperl-forward-re): Suppress an
error message about "End of string/RE not found" when we are
at the end of a narrowed buffer where the end of a RE is
temporarily unavailable (Bug#37127).

* test/lisp/progmodes/cperl-mode-tests.el (cperl-bug37127):
Add a test to verify that the message is suppressed when
inappropriate, but appears when the RE *is* incomplete.
---
 lisp/progmodes/cperl-mode.el            |  7 ++++++
 test/lisp/progmodes/cperl-mode-tests.el | 29 +++++++++++++++++++++++++
 2 files changed, 36 insertions(+)

diff --git a/lisp/progmodes/cperl-mode.el b/lisp/progmodes/cperl-mode.el
index ebbea6bed9..94f42cb2bc 100644
--- a/lisp/progmodes/cperl-mode.el
+++ b/lisp/progmodes/cperl-mode.el
@@ -3225,6 +3225,13 @@ cperl-forward-re
 		 (and cperl-brace-recursing
 		      (or (eq ostart  ?\{)
 			  (eq starter ?\{)))
+		 ;; If we are at the end of a narrowed buffer, then a
+		 ;; scan error should not be reported to the user.
+		 ;; This situation actually happens when a closing
+		 ;; paren is entered in a regular expression.
+		 ;; Reported in Bug#37127.
+		 (and (eobp) (buffer-narrowed-p)
+		      (equal (car bb) 'scan-error))
 		 (message
 		  "End of `%s%s%c ... %c' string/RE not found: %s"
 		  argument
diff --git a/test/lisp/progmodes/cperl-mode-tests.el b/test/lisp/progmodes/cperl-mode-tests.el
index e67678cf6b..4b949bc9a7 100644
--- a/test/lisp/progmodes/cperl-mode-tests.el
+++ b/test/lisp/progmodes/cperl-mode-tests.el
@@ -218,4 +218,33 @@ cperl-mode-fontify-punct-vars
         (should (equal (nth 3 (syntax-ppss)) nil))
         (should (equal (nth 4 (syntax-ppss)) t))))))
 
+(ert-deftest cperl-bug37127 ()
+  "Verify that closing a paren in a regex goes without a message.
+Also check that the message is issued if the regex terminator is
+missing."
+  (let (collected-messages)
+    ;; Part one: Regex is ok, no messages
+    (ert-with-message-capture collected-messages
+      (with-temp-buffer
+        (insert "$_ =~ /(./;")
+        (cperl-mode)
+        (goto-char (point-min))
+        (search-forward ".")
+        (let ((last-command-event ?\)))
+          (cperl-electric-rparen 1)
+          (cperl-find-pods-heres (point-min) (point-max) t)))
+      (should (string-equal collected-messages "")))
+    ;; part two: Regex terminator missing -> message
+    (ert-with-message-capture collected-messages
+      (with-temp-buffer
+        (insert "$_ =~ /(..;")
+        (goto-char (point-min))
+        (cperl-mode)
+        (search-forward ".")
+        (let ((last-command-event ?\)))
+          (cperl-electric-rparen 1)
+          (cperl-find-pods-heres (point-min) (point-max) t)))
+      (should (string-match "^End of .* string/RE"
+                            collected-messages)))))
+
 ;;; cperl-mode-tests.el ends here
-- 
2.20.1

bug#37127: [PATCH] cperl-mode: Suppress a misleading message

[Lars Ingebrigtsen]

haj@posteo.de (Harald Jörg) writes:

> The patch suppresses the message if the following conditions are met:
>    1) The buffer is currently narrowed
>    2) We are at the end of the (narrowed) buffer
>    3) The error in question is of type 'scan-error

Makes sense to me, so I've pushed the change to Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#37127: [PATCH] cperl-mode: Suppress a misleading message

[Stefan Monnier]

> +(ert-deftest cperl-bug37127 ()
[...]
> +    ;; part two: Regex terminator missing -> message
> +    (ert-with-message-capture collected-messages
> +      (with-temp-buffer
> +        (insert "$_ =~ /(..;")
> +        (goto-char (point-min))
> +        (cperl-mode)
> +        (search-forward ".")
> +        (let ((last-command-event ?\)))
> +          (cperl-electric-rparen 1)
> +          (cperl-find-pods-heres (point-min) (point-max) t)))
> +      (should (string-match "^End of .* string/RE"
> +                            collected-messages)))))

Why is this behavior desirable?

I mean, I don't necessarily mind it, but as a user I find it odd that
typing a `)` which has a matching `(` nearby (which can be found without
crossing any string/RE boundary) should emit a warning about some
"unrelated" surrounding entity like the RE in which it is located.

Emacs usually doesn't emit any such warning when editing within an
unclosed string.

I don't think we should necessarily change CPerl's behavior in this
regard, but that we shouldn't consider it a feature and thus shouldn't
enforce it in our tests.


        Stefan

bug#37127: [PATCH] cperl-mode: Suppress a misleading message

[Harald Jörg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> +(ert-deftest cperl-bug37127 ()
> [...]
>> +    ;; part two: Regex terminator missing -> message
>> +    (ert-with-message-capture collected-messages
>> +      (with-temp-buffer
>> +        (insert "$_ =~ /(..;")
>> +        (goto-char (point-min))
>> +        (cperl-mode)
>> +        (search-forward ".")
>> +        (let ((last-command-event ?\)))
>> +          (cperl-electric-rparen 1)
>> +          (cperl-find-pods-heres (point-min) (point-max) t)))
>> +      (should (string-match "^End of .* string/RE"
>> +                            collected-messages)))))
>
> Why is this behavior desirable?

> I mean, I don't necessarily mind it, but as a user I find it odd that
> typing a `)` which has a matching `(` nearby (which can be found without
> crossing any string/RE boundary) should emit a warning about some
> "unrelated" surrounding entity like the RE in which it is located.

In an unterminated RE, the message will appear for every single
character you type, until the RE is terminated.  I'd find it odd if the
`)` was the only character where the message didn't appear :)

> Emacs usually doesn't emit any such warning when editing within an
> unclosed string.

That's true.  However, unclosed strings are rather simple constructs
when compared to Perl's quote-like operators.  Often, in particular with
the /x modifier, they span several lines.  The message contains
information about which operator is currently being processed, and also
what terminator is used.  In Perl, almost any non-whitespace character
can be used as a delimiter, including letters, quotes, comment starters,
and colons.  So, I think the warning is ok as a real-time syntax check.

> I don't think we should necessarily change CPerl's behavior in this
> regard, but that we shouldn't consider it a feature and thus shouldn't
> enforce it in our tests.

I see now that at least this test should be skipped in Perl mode, which
I failed to do.  Again.  Sorry for that.  In general, handling of REs
with non-standard delimiters is one of the areas where Perl mode has
significant deficiencies.

But of course, I'm also fine with just deleting this test case.  I wrote
it more out of a habit to check that the fix doesn't change the behavior
in other situations.
-- 
Cheers,
haj

bug#37127: [PATCH] cperl-mode: Suppress a misleading message

[Stefan Monnier]

>> I mean, I don't necessarily mind it, but as a user I find it odd that
>> typing a `)` which has a matching `(` nearby (which can be found without
>> crossing any string/RE boundary) should emit a warning about some
>> "unrelated" surrounding entity like the RE in which it is located.
> In an unterminated RE, the message will appear for every single
> character you type, until the RE is terminated.  I'd find it odd if the
> `)` was the only character where the message didn't appear :)

I agree that `)` should be no different.  And while as a user I find
such messages more annoying than helpful (I much prefer to be warned by
some font-lock highlighting (e.g. by "bleeding" past what I expected to
be the end) or something like a tooltip), I'm OK with the current
behavior.  I just don't think that not emitting the message should
trigger a test failure.

> In Perl, almost any non-whitespace character can be used as
> a delimiter, including letters, quotes, comment starters, and colons.

Yes, I remember that from when I wrote the corresponding
syntax-propertize code for `perl-mode` ;-)

> I see now that at least this test should be skipped in Perl mode, which
> I failed to do.  Again.  Sorry for that.

No problem.

BTW, I just noticed that if I revert your patch to cperl-mode.el, the
test still succeeds :-(

> In general, handling of REs with non-standard delimiters is one of the
> areas where Perl mode has significant deficiencies.

Hmm... I thought I had managed to make it cover most cases back then.
I'd be interested to know which cases I missed (or which new cases were
introduced since then: after all it was quite some years ago).

In any case, along the way I decided that this bug was in large part to
blame on blink-matching-open because it calls `syntax-propertize` from
within narrowing.  So I changed it which made your `cperl-mode`
patch unnecessary.  I also tweaked your test so that it does fail in the
old code (and passes with the new code) and so it also works in
`perl-mode` (except for the second part which I kept but which would
fail in `perl-mode`).
The patch I installed can be found below.


        Stefan


diff --git a/lisp/progmodes/cperl-mode.el b/lisp/progmodes/cperl-mode.el
index 94f42cb2bc..ebbea6bed9 100644
--- a/lisp/progmodes/cperl-mode.el
+++ b/lisp/progmodes/cperl-mode.el
@@ -3225,13 +3225,6 @@ cperl-forward-re
 		 (and cperl-brace-recursing
 		      (or (eq ostart  ?\{)
 			  (eq starter ?\{)))
-		 ;; If we are at the end of a narrowed buffer, then a
-		 ;; scan error should not be reported to the user.
-		 ;; This situation actually happens when a closing
-		 ;; paren is entered in a regular expression.
-		 ;; Reported in Bug#37127.
-		 (and (eobp) (buffer-narrowed-p)
-		      (equal (car bb) 'scan-error))
 		 (message
 		  "End of `%s%s%c ... %c' string/RE not found: %s"
 		  argument
diff --git a/lisp/simple.el b/lisp/simple.el
index 2e40e3261c..b1b9c88b32 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -8014,6 +8014,7 @@ blink-matching-open
 	   (blinkpos
             (save-excursion
               (save-restriction
+		(syntax-propertize (point))
                 (if blink-matching-paren-distance
                     (narrow-to-region
                      (max (minibuffer-prompt-end) ;(point-min) unless minibuf.
@@ -8024,7 +8025,7 @@ blink-matching-open
                             (not blink-matching-paren-dont-ignore-comments))))
                   (condition-case ()
                       (progn
-			(syntax-propertize (point))
+			;; (syntax-propertize (point)) ;??
                         (forward-sexp -1)
                         ;; backward-sexp skips backward over prefix chars,
                         ;; so move back to the matching paren.
diff --git a/test/lisp/progmodes/cperl-mode-tests.el b/test/lisp/progmodes/cperl-mode-tests.el
index 75010f7d0f..33ebcccde8 100644
--- a/test/lisp/progmodes/cperl-mode-tests.el
+++ b/test/lisp/progmodes/cperl-mode-tests.el
@@ -224,28 +224,33 @@ cperl-bug37127
   "Verify that closing a paren in a regex goes without a message.
 Also check that the message is issued if the regex terminator is
 missing."
-  (let (collected-messages)
-    ;; Part one: Regex is ok, no messages
-    (ert-with-message-capture collected-messages
-      (with-temp-buffer
-        (insert "$_ =~ /(./;")
-        (cperl-mode)
-        (goto-char (point-min))
-        (search-forward ".")
-        (let ((last-command-event ?\)))
-          (cperl-electric-rparen 1)
-          (cperl-find-pods-heres (point-min) (point-max) t)))
-      (should (string-equal collected-messages "")))
-    ;; part two: Regex terminator missing -> message
+  ;; Part one: Regex is ok, no messages
+  (ert-with-message-capture collected-messages
+    (with-temp-buffer
+      (insert "$_ =~ /(./;")
+      (funcall cperl-test-mode)
+      (goto-char (point-min))
+      (search-forward ".")
+      (let ((last-command-event ?\))
+            ;; Don't emit "Matches ..." even if not visible (e.g. in batch).
+            (blink-matching-paren 'jump-offscreen))
+        (self-insert-command 1)
+        (blink-matching-open))
+      (syntax-propertize (point-max)))
+    (should (string-equal collected-messages "")))
+  ;; part two: Regex terminator missing -> message
+  (when (eq cperl-test-mode #'cperl-mode)
+    ;; This test is only run in `cperl-mode' because only cperl-mode
+    ;; emits a message to warn about such unclosed REs.
     (ert-with-message-capture collected-messages
       (with-temp-buffer
         (insert "$_ =~ /(..;")
         (goto-char (point-min))
-        (cperl-mode)
+        (funcall cperl-test-mode)
         (search-forward ".")
         (let ((last-command-event ?\)))
-          (cperl-electric-rparen 1)
-          (cperl-find-pods-heres (point-min) (point-max) t)))
+          (self-insert-command 1))
+        (syntax-propertize (point-max)))
       (should (string-match "^End of .* string/RE"
                             collected-messages)))))
 

bug#37127: [PATCH] cperl-mode: Suppress a misleading message

[Harald Jörg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> In an unterminated RE, the message will appear for every single
>> character you type, until the RE is terminated.  I'd find it odd if the
>> `)` was the only character where the message didn't appear :)
>
> I agree that `)` should be no different.  And while as a user I find
> such messages more annoying than helpful (I much prefer to be warned by
> some font-lock highlighting (e.g. by "bleeding" past what I expected to
> be the end) or something like a tooltip), I'm OK with the current
> behavior.  I just don't think that not emitting the message should
> trigger a test failure.

I agree.  Also, I would be fine with different warning mechanisms, but I
guess these need more work (and are not in the scope for the current bug).

>> In Perl, almost any non-whitespace character can be used as
>> a delimiter, including letters, quotes, comment starters, and colons.
>
> Yes, I remember that from when I wrote the corresponding
> syntax-propertize code for `perl-mode` ;-)
>
>> I see now that at least this test should be skipped in Perl mode, which
>> I failed to do.  Again.  Sorry for that.
>
> No problem.
>
> BTW, I just noticed that if I revert your patch to cperl-mode.el, the
> test still succeeds :-(

Maybe I should look into that....  When run manually, the symptom is
there, in various Emacs versions, and goes away with the patch.  Without
the patch, the test fails when I run ERT interactively with emacs -Q in
Emacs 26.1.  It succeeds without the patch when I run ERT in batch :(

I know I had several attempts to trick ERT into simulating a closing
paren keyboard event, but apparently still failed.  I suspect the tests
don't make it past The caller of blink-matching-open
(blink-paren-post-self-insert-function), which tests for interactive
use.  Your version calls blink-matching-open directly and avoids that
problem.

>> In general, handling of REs with non-standard delimiters is one of the
>> areas where Perl mode has significant deficiencies.

> Hmm... I thought I had managed to make it cover most cases back then.
> I'd be interested to know which cases I missed (or which new cases were
> introduced since then: after all it was quite some years ago).

I'll send that off-list (it has nothing to do with the current bug).

> In any case, along the way I decided that this bug was in large part to
> blame on blink-matching-open because it calls `syntax-propertize` from
> within narrowing.  So I changed it which made your `cperl-mode`
> patch unnecessary.  I also tweaked your test so that it does fail in the
> old code (and passes with the new code) and so it also works in
> `perl-mode` (except for the second part which I kept but which would
> fail in `perl-mode`).

This is excellent!  I didn't dare to even think about changing this
function which apparently works for all other modes, so I tried to work
around the issue.

> The patch I installed can be found below.

Great!  Much better now.  Many thanks!
-- 
Cheers,
haj

bug#37127: [PATCH] A final tweak: Skip the test for older Emacsen

[Harald Jörg]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

The current fix for this bug is in simple.el.  This comes with the side
effect that it will not be available in older Emacs versions when CPerl
mode makes its way to GNU ELPA.

The bug is completely harmless, I guess that porting the fix to older
versions isn't worth the effort.  I suggest to just skip the test when
run under Emacs < 28, though this isn't strictly mandatory in the Emacs
repository.
--
Cheers,
haj

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Skip a test for older Emacsen --]
[-- Type: text/x-diff, Size: 1302 bytes --]

From 365163de04a42ea9a24a56a8d68781988def8f42 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Harald=20J=C3=B6rg?= <haj@posteo.de>
Date: Mon, 2 Nov 2020 23:44:58 +0100
Subject: [PATCH] cperl-mode: Skip a test for older Emacsen (preparing for
 ELPA)

* test/lisp/progmodes/cperl-mode-tests.el (cperl-bug37127):
Skip this test for older Emacsen.  The bug has been fixed
in Emacs, but outside of CPerl mode, and therefore will not
be available for older versions via ELPA.
---
 test/lisp/progmodes/cperl-mode-tests.el | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/test/lisp/progmodes/cperl-mode-tests.el b/test/lisp/progmodes/cperl-mode-tests.el
index 9a7b5e4d6d..dcde3b68a0 100644
--- a/test/lisp/progmodes/cperl-mode-tests.el
+++ b/test/lisp/progmodes/cperl-mode-tests.el
@@ -224,6 +224,10 @@ cperl-bug37127
   "Verify that closing a paren in a regex goes without a message.
 Also check that the message is issued if the regex terminator is
 missing."
+  ;; The actual fix for this bug is in simple.el, which is not
+  ;; backported to older versions of Emacs.  Therefore we skip this
+  ;; test if we're running Emacs 27 or older.
+  (skip-unless (< 27 emacs-major-version))
   ;; Part one: Regex is ok, no messages
   (ert-with-message-capture collected-messages
     (with-temp-buffer
-- 
2.20.1

bug#37127: [PATCH] A final tweak: Skip the test for older Emacsen

[Stefan Kangas]

haj@posteo.de (Harald Jörg) writes:

> The current fix for this bug is in simple.el.  This comes with the side
> effect that it will not be available in older Emacs versions when CPerl
> mode makes its way to GNU ELPA.
>
> The bug is completely harmless, I guess that porting the fix to older
> versions isn't worth the effort.  I suggest to just skip the test when
> run under Emacs < 28, though this isn't strictly mandatory in the Emacs
> repository.

Makes sense, pushed to master as commit 2800513af5.