bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#60768: 30.0.50; edebug-instrument-function off by one


From: No Wayman
Subject: bug#60768: 30.0.50; edebug-instrument-function off by one
Date: Thu, 13 Jul 2023 08:03:55 -0400
User-agent: mu4e 1.11.9; emacs 30.0.50


Eli Zaretskii <eliz@gnu.org> writes:

From: No Wayman <iarchivedmywholelife@gmail.com>
Date: Thu, 12 Jan 2023 21:27:06 -0500

1. Save the following elisp to /tmp/test.el:


--8<---------------cut here---------------start------------->8---
;; -*- lexical-binding: t; -*-

;;;###autoload
(defun one ()
  "ONE"
  (1+ 0))

(defun two ()
  "TWO"
  (1+ (one)))

(defun three ()
  "THREE"
  (1+ (two)))

(provide 'test)
--8<---------------cut here---------------end--------------->8---

2. Run emacs from the command line with the following:

emacs -Q --batch -l /tmp/test.el --eval "(progn (require 'edebug) (edebug-instrument-function #'one))"

Expected output: Edebug: one
Actual output: Edebug: two

If you repeat the test with an additional autoload cookie added above function "two", function one is correctly instrumented.

If you repeat it with an autoload cookie only above function "three", function two is, incorrectly, instrumented.

My hunch is find-function-search-for-symbol being thrown off somehow.

It's not a real problem, and it has nothing to do with the autoload
cookie, AFAICT.  If you modify edebug.el like below:

diff --git a/lisp/emacs-lisp/edebug.el b/lisp/emacs-lisp/edebug.el
index 2f7d03e..0ac51ad 100644
--- a/lisp/emacs-lisp/edebug.el
+++ b/lisp/emacs-lisp/edebug.el
@@ -518,6 +518,7 @@ edebug-read-top-level-form
;; Don't enter Edebug while doing that, in case we're trying to
         ;; instrument things like end-of-defun.
         (edebug-active t))
+    (save-excursion (end-of-defun))
     (end-of-defun)
     (beginning-of-defun)
     (prog1

i.e., add one call to end-of-defun whose result is thrown away, before
the _real_ call to end-of-defun, the problems go away.

The reason seems to be that end-of-defun calls scan-sexps, and the
first call to scan-sexps does something that wasn't done before.

Stefan, any ideas what could that be?  Any hints where to look?

Any chance of applying this workaround with a note to investigate more for a proper fix?






reply via email to

[Prev in Thread] Current Thread [Next in Thread]