Subject: bug#54119: 29.0.50; Edebug: Jumping commands in recursive definitions

From: Michael Heerdegen <[email-masked]>
Date: Wed, 23 Feb 2022 05:09:39 +0100

Hello,

the Edebug sexp jumping commands f and o can behave surprisingly (I
would say annoyingly and wrong) when used near recursive calls of the
current function.

Let me demonstrate the problem with an example:

Instrument

#+begin_src emacs-lisp
(defun my-factorial (n) (if (< n 2) 1 (* n (my-factorial (1- n)))))
#+end_src
                                           ^
                                           |
M-: (my-factorial 5) RET and hit SPC until the cursor is before the
front of the recursive call of `my-factorial' (as indicated).  Hit f.
You get "2" as result.

This is quite unexpected, one would expect (my-factorial 4) ==> 24.

What happened is that Edebug does not really "jump" over the following
expression, it just sets a breakpoint after it and enters "go"
mode. That breakpoint "breaks" the next time it is passed, and that is,
in the above example, at the end of the innermost recursion, AFAIU.

The same thing can happen with `o'.  When that kind of thing happens, it
can become a very tricky task to edebug what you wanted to.

I don't know - can we make those "internal" breakpoints conditional and
let the condition check the recursion level, somehow?  Although, even
then, some obscure kinds of code using catch and throw might still
behave surprisingly.  Edebug would somehow have to check that the jumped
over execution frame terminates normally, or something like that.

TIA,

Michael.

In GNU Emacs 29.0.50 (build 33, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
 of 2022-02-23 built on drachen
Repository revision: be7c8c79eb874e3297c8492b1363fb0b8c433fae
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)