GNU bug report logs - #37127
27.0.50; in cperl mode, scan-error Unbalanced parentheses

Previous Next

Package: emacs;

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

Date: Wed, 21 Aug 2019 12:18:01 UTC

Severity: minor

Tags: confirmed, fixed

Found in version 27.0.50

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 37127 in the body.
You can then email your comments to 37127 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#37127; Package emacs. (Wed, 21 Aug 2019 12:18:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Vincent Lefevre <vincent <at> vinc17.net>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 21 Aug 2019 12:18:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vincent Lefevre <vincent <at> vinc17.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; in cperl mode, scan-error Unbalanced parentheses
Date: Wed, 21 Aug 2019 14:17:01 +0200
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))




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37127; Package emacs. (Thu, 03 Oct 2019 23:03:01 GMT) Full text and rfc822 format available.

Message #8 received at 37127 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Vincent Lefevre <vincent <at> vinc17.net>
Cc: 37127 <at> debbugs.gnu.org
Subject: Re: bug#37127: 27.0.50;
 in cperl mode, scan-error Unbalanced parentheses
Date: Fri, 4 Oct 2019 01:02:14 +0200
tags 37127 + confirmed
quit

Vincent Lefevre <vincent <at> 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




Added tag(s) confirmed. Request was from Stefan Kangas <stefan <at> marxist.se> to control <at> debbugs.gnu.org. (Thu, 03 Oct 2019 23:03:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37127; Package emacs. (Thu, 29 Oct 2020 21:13:01 GMT) Full text and rfc822 format available.

Message #13 received at 37127 <at> debbugs.gnu.org (full text, mbox):

From: haj <at> posteo.de (Harald Jörg)
To: 37127 <at> debbugs.gnu.org
Subject: [PATCH] cperl-mode: Suppress a misleading message
Date: Thu, 29 Oct 2020 22:11:58 +0100
[Message part 1 (text/plain, inline)]
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
[0001-Suppress-a-misleading-message-when-closing-a-paren-i.patch (text/x-diff, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37127; Package emacs. (Fri, 30 Oct 2020 12:25:02 GMT) Full text and rfc822 format available.

Message #16 received at 37127 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: haj <at> posteo.de (Harald Jörg)
Cc: 37127 <at> debbugs.gnu.org
Subject: Re: bug#37127: [PATCH] cperl-mode: Suppress a misleading message
Date: Fri, 30 Oct 2020 13:24:26 +0100
haj <at> 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




Added tag(s) fixed. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Fri, 30 Oct 2020 12:25:02 GMT) Full text and rfc822 format available.

bug marked as fixed in version 28.1, send any further explanations to 37127 <at> debbugs.gnu.org and Vincent Lefevre <vincent <at> vinc17.net> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Fri, 30 Oct 2020 12:25:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37127; Package emacs. (Fri, 30 Oct 2020 14:31:02 GMT) Full text and rfc822 format available.

Message #23 received at 37127 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: haj <at> posteo.de (Harald Jörg)
Cc: 37127 <at> debbugs.gnu.org
Subject: Re: bug#37127: [PATCH] cperl-mode: Suppress a misleading message
Date: Fri, 30 Oct 2020 10:30:04 -0400
> +(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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37127; Package emacs. (Fri, 30 Oct 2020 20:20:02 GMT) Full text and rfc822 format available.

Message #26 received at 37127 <at> debbugs.gnu.org (full text, mbox):

From: haj <at> posteo.de (Harald Jörg)
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 37127 <at> debbugs.gnu.org
Subject: Re: bug#37127: [PATCH] cperl-mode: Suppress a misleading message
Date: Fri, 30 Oct 2020 21:19:41 +0100
Stefan Monnier <monnier <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37127; Package emacs. (Fri, 30 Oct 2020 22:13:01 GMT) Full text and rfc822 format available.

Message #29 received at 37127 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: haj <at> posteo.de (Harald Jörg)
Cc: 37127 <at> debbugs.gnu.org
Subject: Re: bug#37127: [PATCH] cperl-mode: Suppress a misleading message
Date: Fri, 30 Oct 2020 18:12:13 -0400
>> 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)))))
 





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37127; Package emacs. (Sat, 31 Oct 2020 01:10:02 GMT) Full text and rfc822 format available.

Message #32 received at 37127 <at> debbugs.gnu.org (full text, mbox):

From: haj <at> posteo.de (Harald Jörg)
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 37127 <at> debbugs.gnu.org
Subject: Re: bug#37127: [PATCH] cperl-mode: Suppress a misleading message
Date: Sat, 31 Oct 2020 02:09:45 +0100
Stefan Monnier <monnier <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37127; Package emacs. (Mon, 02 Nov 2020 22:54:02 GMT) Full text and rfc822 format available.

Message #35 received at 37127 <at> debbugs.gnu.org (full text, mbox):

From: haj <at> posteo.de (Harald Jörg)
To: 37127 <at> debbugs.gnu.org
Subject: [PATCH] A final tweak: Skip the test for older Emacsen
Date: Mon, 02 Nov 2020 23:52:56 +0100
[Message part 1 (text/plain, inline)]
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
[0001-cperl-mode-Skip-a-test-for-older-Emacsen-preparing-f.patch (text/x-diff, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37127; Package emacs. (Mon, 02 Nov 2020 23:15:02 GMT) Full text and rfc822 format available.

Message #38 received at 37127 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Harald Jörg <haj <at> posteo.de>, 37127 <at> debbugs.gnu.org
Subject: Re: bug#37127: [PATCH] A final tweak: Skip the test for older Emacsen
Date: Mon, 2 Nov 2020 23:13:58 +0000
haj <at> 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.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 01 Dec 2020 12:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 118 days ago.

Previous Next


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