bug#10483: 24.0.92; cperl-indent-exp hangs

bug#10483: 24.0.92; cperl-indent-exp hangs

[Eric Hanchrow]

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from `emacs -Q':

1. Save the following to (e.g.) /tmp/bug.el:

===8<======8<======8<======8<======8<======8<======8<======8<======8<===
    (switch-to-buffer "frotz.pl")
    (cperl-mode)
    (insert "poop ('foo', \n      'bar')")
    ;(insert ";")
    (goto-char 5)
    (cperl-indent-exp)
===8<======8<======8<======8<======8<======8<======8<======8<======8<===

2.  Invoke emacs like "emacs -Q --load /tmp/bug.el".

3.  Note that Emacs has hung.

If you'd like ...

4.  Kill the hung emacs

5.  Uncomment the fourth line in bug.el

6. Invoke emacs the same way again

7. Note that Emacs is perfectly happy.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/home/ehanchrow/local/emacs-master-gui/share/emacs/24.0.92/etc/DEBUG.


In GNU Emacs 24.0.92.3 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1)
 of 2012-01-03 on rampage.sea
Windowing system distributor `The X.Org Foundation', version 11.0.10402000
configured using `configure  '--prefix=/home/ehanchrow/local/emacs-master-gui''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: C
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-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
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x r e p o r t - e m a c s - b u g <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr message format-spec rfc822 mml easymenu
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader
emacsbug time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel
x-win x-dnd tool-bar dnd fontset image fringe lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs
button faces cus-face files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty emacs)

bug#10483: [PATCH] cperl-mode: Avoid endless loop

[Harald Jörg]

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

That bug has a few more manifestations. An endless loop
occurred whenever a statement ended in a closing paren, and
the statement was not terminated on the same line.

[-- Attachment #2: 0001-2020-08-31-Harald-J-rg-haj-posteo.de.patch --]
[-- Type: text/x-patch, Size: 1753 bytes --]

From 325dc859a5ed9a912f15ec4e7e123b3fe3bde299 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Harald=20J=C3=B6rg?= <haj@posteo.de>
Date: Mon, 31 Aug 2020 18:35:53 +0200
Subject: [PATCH] =?UTF-8?q?2020-08-31=20=20Harald=20J=C3=B6rg=20=20<haj@po?=
 =?UTF-8?q?steo.de>?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

 * lisp/progmodes/cperl-mode.el (cperl-indent-exp): Fix (Bug#10483)
 Perl expressions (e.g. function calls) ending in ")" without
 statement terminator on the same line no longer loop endlessly.
---
 lisp/progmodes/cperl-mode.el | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/lisp/progmodes/cperl-mode.el b/lisp/progmodes/cperl-mode.el
index 44579cfd38..f6ad0b7e6d 100644
--- a/lisp/progmodes/cperl-mode.el
+++ b/lisp/progmodes/cperl-mode.el
@@ -4820,9 +4820,10 @@ cperl-indent-exp
 	  (while (< (point) tmp-end)
 	    (parse-partial-sexp (point) tmp-end nil t) ; To start-sexp or eol
 	    (or (eolp) (forward-sexp 1)))
-	  (if (> (point) tmp-end)	; Yes, there an unfinished block
+	  (if (> (point) tmp-end)	; Check for an unfinished block
 	      nil
 	    (if (eq ?\) (preceding-char))
+		;; closing parens can be preceded by up to three sexps
 		(progn ;; Plan B: find by REGEXP block followup this line
 		  (setq top (point))
 		  (condition-case nil
@@ -4843,7 +4844,9 @@ cperl-indent-exp
 			    (progn
 			      (goto-char top)
 			      (forward-sexp 1)
-			      (setq top (point)))))
+			      (setq top (point)))
+			  ;; no block to be processed: expression ends here
+			  (setq done t)))
 		    (error (setq done t)))
 		  (goto-char top))
 	      (if (looking-at		; Try Plan C: continuation block
-- 
2.20.1

bug#10483: [PATCH] cperl-mode: Avoid endless loop

[Eli Zaretskii]

> From: Harald Jörg <haj@posteo.de>
> Date: Mon, 31 Aug 2020 19:06:08 +0200
> 
> That bug has a few more manifestations. An endless loop
> occurred whenever a statement ended in a closing paren, and
> the statement was not terminated on the same line.

Thanks, but could we please also have a test for this issue, so that
the bug never happens again?

bug#10483: [PATCH] cperl-mode: Avoid endless loop

[Harald Jörg]

On 8/31/20 7:24 PM, Eli Zaretskii wrote:
>> From: Harald Jörg <haj@posteo.de>
>> Date: Mon, 31 Aug 2020 19:06:08 +0200
>>
>> That bug has a few more manifestations. An endless loop
>> occurred whenever a statement ended in a closing paren, and
>> the statement was not terminated on the same line.
> 
> Thanks, but could we please also have a test for this issue, so that
> the bug never happens again?

Sure... I can prepare another patch.  The test also ought to verify
that terminating the while loop didn't damage cperl-mode's ability to
indent the compound statements it handles in this section of code.

I was hesitating in this particular case because _if_ this issue ever
happens again, then the test just hangs forever.

Is there a safeguard against this?
--
Cheers,
haj

bug#10483: [PATCH] cperl-mode: Avoid endless loop

[Eli Zaretskii]

> Cc: 10483@debbugs.gnu.org
> From: Harald Jörg <haj@posteo.de>
> Date: Mon, 31 Aug 2020 20:08:06 +0200
> 
> I was hesitating in this particular case because _if_ this issue ever
> happens again, then the test just hangs forever.
> 
> Is there a safeguard against this?

You could run the test in a subordinate Emacs process, and have the
parent process wait for it to complete with a timeout.

bug#10483: [PATCH] cperl-mode: Avoid endless loop

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> You could run the test in a subordinate Emacs process, and have the
> parent process wait for it to complete with a timeout.

Do we have any test cases working like that today?  What would be the
best way to do it?

bug#10483: [PATCH] cperl-mode: Avoid endless loop

[Harald Jörg]

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

[Re-sent to list: my first reply went to Eli Zaretskii only.  Sorry.]
On 8/31/20 8:49 PM, Eli Zaretskii wrote:
>> Cc: 10483@debbugs.gnu.org
>> From: Harald Jörg <haj@posteo.de>
>> Date: Mon, 31 Aug 2020 20:08:06 +0200
>>
>> I was hesitating in this particular case because _if_ this issue ever
>> happens again, then the test just hangs forever.
>>
>> Is there a safeguard against this?
> 
> You could run the test in a subordinate Emacs process, and have the
> parent process wait for it to complete with a timeout.

So be it: My attempt to do this is attached, together with tests
to verify that my loop termination isn't harmful to the function.

As always, a review is welcome. I still haven't much experience
in Elisp.  I haven't found examples to steal from, and also missed
the fork/waitpid stuff which I use for such tasks in Perl.
-- 
Cheers,
haj

[-- Attachment #2: 0001-2020-09-01-Harald-J-rg-haj-posteo.de.patch --]
[-- Type: text/x-patch, Size: 7082 bytes --]

From eb41f40648ee6696acc54964f3aac364336c06e3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Harald=20J=C3=B6rg?= <haj@posteo.de>
Date: Tue, 1 Sep 2020 15:50:54 +0200
Subject: [PATCH] =?UTF-8?q?2020-09-01=20=20Harald=20J=C3=B6rg=20=20<haj@po?=
 =?UTF-8?q?steo.de>?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

 * test/lisp/progmodes/cperl-mode-tests.el (cperl-mode-test-bug-10483):
 Add this test to verify that Emacs doesn't hang over a Perl statement
 which isn't terminated on the same line.

 * test/lisp/progmodes/cperl-mode-tests.el (cperl-mode-test-indent-exp):
 Verify that the fix avoiding the endless loop doesn't stop indenting
 from working properly.

 * test/lisp/progmodes/cperl-mode-resources/cperl-indent-exp.pl:
 Code and result snippets for testing `cperl-indent-exp'
---
 .../cperl-mode-resources/cperl-indent-exp.pl  | 52 +++++++++++
 test/lisp/progmodes/cperl-mode-tests.el       | 91 ++++++++++++++++++-
 2 files changed, 139 insertions(+), 4 deletions(-)
 create mode 100644 test/lisp/progmodes/cperl-mode-resources/cperl-indent-exp.pl

diff --git a/test/lisp/progmodes/cperl-mode-resources/cperl-indent-exp.pl b/test/lisp/progmodes/cperl-mode-resources/cperl-indent-exp.pl
new file mode 100644
index 0000000000..4a9842ffa5
--- /dev/null
+++ b/test/lisp/progmodes/cperl-mode-resources/cperl-indent-exp.pl
@@ -0,0 +1,52 @@
+#!/usr/bin/env perl
+use strict;
+use warnings;
+use 5.020;
+
+# This file contains test input and expected output for the tests in
+# cperl-mode-tests.el, cperl-mode-test-indent-exp.  The code is
+# syntactically valid, but doesn't make much sense.
+
+# -------- for loop: input --------
+for my $foo (@ARGV)
+{
+...;
+}
+# -------- for loop: expected output --------
+for my $foo (@ARGV) {
+  ...;
+}
+# -------- for loop: end --------
+
+# -------- while loop: input --------
+{
+while (1)
+{
+say "boring loop";
+}
+continue
+{
+last; # no endless loop, though
+}
+}
+# -------- while loop: expected output --------
+{
+  while (1) {
+    say "boring loop";
+  } continue {
+    last; # no endless loop, though
+  }
+}
+# -------- while loop: end --------
+
+# -------- if-then-else: input --------
+if (my $foo) { bar() } elsif (quux()) { baz() } else { quuux }
+# -------- if-then-else: expected output --------
+if (my $foo) {
+  bar();
+} elsif (quux()) {
+  baz();
+} else {
+  quuux;
+}
+# -------- if-then-else: end --------
diff --git a/test/lisp/progmodes/cperl-mode-tests.el b/test/lisp/progmodes/cperl-mode-tests.el
index be8b42d99a..61412025fc 100644
--- a/test/lisp/progmodes/cperl-mode-tests.el
+++ b/test/lisp/progmodes/cperl-mode-tests.el
@@ -9,15 +9,20 @@
 
 ;;; Commentary:
 
-;; This is a collection of tests for the fontification of CPerl-mode.
-
-;; Run these tests interactively:
-;; (ert-run-tests-interactively '(tag :fontification))
+;; This is a collection of tests for CPerl-mode.
 
 ;;; Code:
 
 (defvar cperl-test-mode #'cperl-mode)
 
+(defvar cperl-mode-tests-data-directory
+  (expand-file-name "lisp/progmodes/cperl-mode-resources"
+                    (or (getenv "EMACS_TEST_DIRECTORY")
+                        (expand-file-name "../../../"
+                                          (or load-file-name
+                                              buffer-file-name))))
+  "Directory containing cperl-mode test data.")
+
 (defun cperl-test-ppss (text regexp)
   "Return the `syntax-ppss' of the first character matched by REGEXP in TEXT."
   (interactive)
@@ -48,4 +53,82 @@ cperl-mode-test-bug-42168
   (let ((code "{ $a- / $b } # /"))
     (should (equal (nth 8 (cperl-test-ppss code "/")) 7))))
 
+(defun cperl-mode-test--run-bug-10483 ()
+  "Runs a short program, intended to be under timer scrutiny.
+This function is intended to be used by an Emacs subprocess in
+batch mode.  The message buffer is used to report the result of
+running `cperl-indent-exp' for a very simple input.  The result
+is expected to be different from the input, to verify that
+indentation actually takes place.."
+  (let ((code "poop ('foo', \n'bar')")) ; see the bug report
+    (message "Test Bug#10483 started")
+    (with-temp-buffer
+      (insert code)
+      (funcall cperl-test-mode)
+      (goto-char (point-min))
+      (search-forward "poop")
+      (cperl-indent-exp)
+      (message "%s" (buffer-string)))))
+
+(ert-deftest cperl-mode-test-bug-10483 ()
+  "Verifies that a piece of code which ends in a paren without a
+statement terminato ron tne same line does not loop forever.  The
+test starts an asynchronous Emacs batch process under timeout
+control."
+  (interactive)
+  (let* ((emacs (concat invocation-directory invocation-name))
+         (test-function 'cperl-mode-test--run-bug-10483)
+         (test-function-name (symbol-name test-function))
+         (test-file (symbol-file test-function 'defun))
+         (ran-out-of-time nil)
+         (process-connection-type nil)
+         runner)
+    (with-temp-buffer
+      (with-timeout (1
+                     (delete-process runner)
+                     (setq ran-out-of-time t))
+        (setq runner (start-process "speedy"
+                                    (current-buffer)
+                                    emacs
+                                    "-batch"
+                                    "--quick"
+                                    "--load" test-file
+                                    "--funcall" test-function-name))
+        (while (accept-process-output runner)))
+      (should (equal ran-out-of-time nil))
+      (goto-char (point-min))
+      ;; just a very simple test for indentation: This should
+      ;; be rather robust with regard to indentation defaults
+      (should (string-match
+               "poop ('foo', \n      'bar')" (buffer-string))))))
+
+(ert-deftest cperl-mode-test-indent-exp ()
+  "Run various tests for `cperl-indent-exp' edge cases.
+These exercise some standard blocks and also the special
+treatment for Perl expressions where a closing paren isn't the
+end of the statement."
+  (let ((file (expand-file-name "cperl-indent-exp.pl"
+                                cperl-mode-tests-data-directory)))
+    (with-temp-buffer
+      (insert-file-contents file)
+      (goto-char (point-min))
+      (while (re-search-forward
+              (concat "^# ?-+ \\_<\\(?1:.+?\\)\\_>: input ?-+\n"
+                      "\\(?2:\\(?:.*\n\\)+?\\)"
+                      "# ?-+ \\1: expected output ?-+\n"
+                      "\\(?3:\\(?:.*\n\\)+?\\)"
+                      "# ?-+ \\1: end ?-+")
+              nil t)
+        (let ((name (match-string 1))
+              (code (match-string 2))
+              (expected (match-string 3))
+              got)
+          (with-temp-buffer
+            (insert code)
+            (goto-char (point-min))
+            (cperl-indent-exp) ; here we go!
+            (setq expected (concat "test case " name ":\n" expected))
+            (setq got (concat "test case " name ":\n" (buffer-string)))
+            (should (equal got expected))))))))
+
 ;;; cperl-mode-tests.el ends here
-- 
2.20.1

bug#10483: [PATCH] cperl-mode: Avoid endless loop

[Lars Ingebrigtsen]

Harald Jörg <haj@posteo.de> writes:

> So be it: My attempt to do this is attached, together with tests
> to verify that my loop termination isn't harmful to the function.

Great; I've applied your fix (along with the test) to Emacs 28.

> As always, a review is welcome. I still haven't much experience
> in Elisp.

Looks good to me.  The only detail is that we normally want the first
line of a doc string to be a complete sentence, and in one case it
wasn't:

+(ert-deftest cperl-mode-test-bug-10483 ()
+  "Verifies that a piece of code which ends in a paren without a
+statement terminato ron tne same line does not loop forever.  The

But this is in the test harness, so I don't think we really have much of
a style convention going here, so I didn't fix that up before applying.

> I haven't found examples to steal from, and also missed the
> fork/waitpid stuff which I use for such tasks in Perl.

Yeah...  Perhaps Emacs should grow some convenience functions for this
stuff?

Anyway, the patch fixes the reported bug here, so I'm closing this bug
report.

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

bug#10483: [PATCH] cperl-mode: Avoid endless loop

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 04 Sep 2020 05:17:45 +0200
> Cc: 10483@debbugs.gnu.org
> 
> > I haven't found examples to steal from, and also missed the
> > fork/waitpid stuff which I use for such tasks in Perl.
> 
> Yeah...  Perhaps Emacs should grow some convenience functions for this
> stuff?

I don't think I understand what's missing in what we have already.
The equivalent of 'fork' is 'start-process', and the equivalent of
'waitpid' is a test of what 'process-status' returns.

bug#10483: [PATCH] cperl-mode: Avoid endless loop

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't think I understand what's missing in what we have already.
> The equivalent of 'fork' is 'start-process', and the equivalent of
> 'waitpid' is a test of what 'process-status' returns.

waitpid waits until a process changes status, doesn't it?  In Emacs Lisp
we have to write a loop over `process-status', which adds latency and
just doesn't seem very elegant.

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

bug#10483: [PATCH] cperl-mode: Avoid endless loop

[Andreas Schwab]

On Sep 04 2020, Lars Ingebrigtsen wrote:

> waitpid waits until a process changes status, doesn't it?  In Emacs Lisp
> we have to write a loop over `process-status', which adds latency and
> just doesn't seem very elegant.

In Emacs you use accept-process-output and a process sentinel.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#10483: [PATCH] cperl-mode: Avoid endless loop

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

> On Sep 04 2020, Lars Ingebrigtsen wrote:
>
>> waitpid waits until a process changes status, doesn't it?  In Emacs Lisp
>> we have to write a loop over `process-status', which adds latency and
>> just doesn't seem very elegant.
>
> In Emacs you use accept-process-output and a process sentinel.

Which isn't very elegant, either.

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

bug#10483: [PATCH] cperl-mode: Avoid endless loop

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: haj@posteo.de,  10483@debbugs.gnu.org
> Date: Fri, 04 Sep 2020 12:41:52 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't think I understand what's missing in what we have already.
> > The equivalent of 'fork' is 'start-process', and the equivalent of
> > 'waitpid' is a test of what 'process-status' returns.
> 
> waitpid waits until a process changes status, doesn't it?  In Emacs Lisp
> we have to write a loop over `process-status', which adds latency and
> just doesn't seem very elegant.

But the advantage of a loop is that you can do something while you
wait.  Whereas if you expose waitpid to Lisp, the Lisp program which
calls it will be parked inside the call, and the entire Emacs session
will stall.  Or what am I missing?

bug#10483: [PATCH] cperl-mode: Avoid endless loop

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  10483@debbugs.gnu.org,  haj@posteo.de
> Date: Fri, 04 Sep 2020 12:55:56 +0200
> 
> > In Emacs you use accept-process-output and a process sentinel.
> 
> Which isn't very elegant, either.

Elegance is in eyes of the beholder.  FWIW, I think what we have is
better suited for interactive program such as Emacs.

bug#10483: [PATCH] cperl-mode: Avoid endless loop

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> But the advantage of a loop is that you can do something while you
> wait.  Whereas if you expose waitpid to Lisp, the Lisp program which
> calls it will be parked inside the call, and the entire Emacs session
> will stall.  Or what am I missing?

No, I'm not talking about actually implementing waitpid, but just adding
some utility functions for handling multi-processing in a bit more
convenient way.  Starting a process and then waiting until it's done
isn't an unusual thing to do, so a wait-for-process function would be
nice (in this instance).

In general, it would be nice if Emacs grew a rich feature set for
synchronisation (thread and process), perhaps based on futures (or
whatever kids these days are using).

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

bug#10483: [PATCH] cperl-mode: Avoid endless loop

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Elegance is in eyes of the beholder.  FWIW, I think what we have is
> better suited for interactive program such as Emacs.

Interactive (editing) things is definitely the Emacs focus, which
explains why the primitives are the way they are.  That doesn't mean we
shouldn't grow functions that make other programming cases easier.

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

bug#10483: [PATCH] cperl-mode: Avoid endless loop

[Andreas Schwab]

On Sep 04 2020, Lars Ingebrigtsen wrote:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> On Sep 04 2020, Lars Ingebrigtsen wrote:
>>
>>> waitpid waits until a process changes status, doesn't it?  In Emacs Lisp
>>> we have to write a loop over `process-status', which adds latency and
>>> just doesn't seem very elegant.
>>
>> In Emacs you use accept-process-output and a process sentinel.
>
> Which isn't very elegant, either.

You asked for the primitives.  There is a lot of tooling around.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#10483: [PATCH] cperl-mode: Avoid endless loop

[Andreas Schwab]

On Sep 04 2020, Eli Zaretskii wrote:

> But the advantage of a loop is that you can do something while you
> wait.  Whereas if you expose waitpid to Lisp, the Lisp program which
> calls it will be parked inside the call, and the entire Emacs session
> will stall.  Or what am I missing?

It doesn't make sense to expose a waitpid-like function to Lisp, as the
Emacs process primitives are already much more elegant.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#10483: [PATCH] cperl-mode: Avoid endless loop

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: haj@posteo.de,  10483@debbugs.gnu.org
> Date: Fri, 04 Sep 2020 13:59:04 +0200
> 
> No, I'm not talking about actually implementing waitpid, but just adding
> some utility functions for handling multi-processing in a bit more
> convenient way.  Starting a process and then waiting until it's done
> isn't an unusual thing to do, so a wait-for-process function would be
> nice (in this instance).

I think at this stage we'd need a more detailed description of the API
you have in mind, to continue this discussion in constructive
directions.  Can you post such an API description?

> In general, it would be nice if Emacs grew a rich feature set for
> synchronisation (thread and process), perhaps based on futures (or
> whatever kids these days are using).

Someone™ should try using the threads for providing such a framework,
it's supposed to be suitable for what you are describing.

bug#10483: [PATCH] cperl-mode: Avoid endless loop

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I think at this stage we'd need a more detailed description of the API
> you have in mind, to continue this discussion in constructive
> directions.  Can you post such an API description?

I do not have any such description, and I did not mean to start a design
discussion here.  :-)  I was just agreeing with the Harald's side not
that it would be nice if Emacs had a more well-developed range of
functions for dealing with processes.

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

bug#10483: [PATCH] Fix a bogus test introduced by treating (Bug#10483)

[Harald Jörg]

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

Severity: minor

The commit 2020-09-04 "Fix infloop when indenting in cperl-mode" for
(Bug#10483) contained a test to make sure that indenting for some edge
cases.  This test 'cperl-mode-test-indent-exp' fails unless cperl-mode
is activated for the buffer.

The attached patch activates cperl-mode, and skips the test under
perl-mode, and avoids dependency on how inline comments are indented.

I couldn't just open a new bug without unarchiving the old one, perhaps
because I've included the old bug number.  Please tell me if it is
better to treat such follow-ups as entirely new bugs.
-- 
Cheers,
haj


[-- Attachment #2: 0001-cperl-mode-Fix-a-test-to-ensure-cperl-mode-is-active.patch --]
[-- Type: text/x-patch, Size: 2321 bytes --]

From 03829b2c8fafe0c83a2629afddc98bb7c2bd98aa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Harald=20J=C3=B6rg?= <haj@posteo.de>
Date: Mon, 5 Oct 2020 12:36:56 +0200
Subject: ; cperl-mode: Fix a test to ensure cperl-mode is active

Tweaking my commit 2020-09-04 "Fix infloop when indenting in cperl-mode":

* test/lisp/progmodes/cperl-mode-tests.el
(cperl-mode-test-indent-exp): Make sure that cperl-mode is active
for testing 'cperl-indent-exp', also skip this test under
perl-mode.

* test/lisp/progmodes/cperl-mode-resources/cperl-indent-exp.pl:
Eliminate dependency on unrelated customizable variables.
---
 test/lisp/progmodes/cperl-mode-resources/cperl-indent-exp.pl | 4 ++--
 test/lisp/progmodes/cperl-mode-tests.el                      | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/test/lisp/progmodes/cperl-mode-resources/cperl-indent-exp.pl b/test/lisp/progmodes/cperl-mode-resources/cperl-indent-exp.pl
index 4a9842ffa5..8c1883a10f 100644
--- a/test/lisp/progmodes/cperl-mode-resources/cperl-indent-exp.pl
+++ b/test/lisp/progmodes/cperl-mode-resources/cperl-indent-exp.pl
@@ -26,7 +26,7 @@
 }
 continue
 {
-last; # no endless loop, though
+last;
 }
 }
 # -------- while loop: expected output --------
@@ -34,7 +34,7 @@
   while (1) {
     say "boring loop";
   } continue {
-    last; # no endless loop, though
+    last;
   }
 }
 # -------- while loop: end --------
diff --git a/test/lisp/progmodes/cperl-mode-tests.el b/test/lisp/progmodes/cperl-mode-tests.el
index f0ff8e9005..20be7ed68c 100644
--- a/test/lisp/progmodes/cperl-mode-tests.el
+++ b/test/lisp/progmodes/cperl-mode-tests.el
@@ -148,6 +148,7 @@ cperl-mode-test-indent-exp
 These exercise some standard blocks and also the special
 treatment for Perl expressions where a closing paren isn't the
 end of the statement."
+  (skip-unless (eq cperl-test-mode #'cperl-mode))
   (let ((file (expand-file-name "cperl-indent-exp.pl"
                                 cperl-mode-tests-data-directory)))
     (with-temp-buffer
@@ -166,6 +167,7 @@ cperl-mode-test-indent-exp
               got)
           (with-temp-buffer
             (insert code)
+	    (cperl-mode)
             (goto-char (point-min))
             (cperl-indent-exp) ; here we go!
             (setq expected (concat "test case " name ":\n" expected))
-- 
2.20.1

bug#10483: [PATCH] Fix a bogus test introduced by treating (Bug#10483)

[Lars Ingebrigtsen]

Harald Jörg <haj@posteo.de> writes:

> The commit 2020-09-04 "Fix infloop when indenting in cperl-mode" for
> (Bug#10483) contained a test to make sure that indenting for some edge
> cases.  This test 'cperl-mode-test-indent-exp' fails unless cperl-mode
> is activated for the buffer.
>
> The attached patch activates cperl-mode, and skips the test under
> perl-mode, and avoids dependency on how inline comments are indented.

Thanks; applied to Emacs 28.

> I couldn't just open a new bug without unarchiving the old one, perhaps
> because I've included the old bug number.  Please tell me if it is
> better to treat such follow-ups as entirely new bugs.

Opening a new bug report would be better, I think, and just refer back
to the previous bug report in the text.

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