From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lute Kamstra Newsgroups: gmane.emacs.devel Subject: Re: Problems with debug-on-entry in the Lisp debugger. Date: Wed, 09 Mar 2005 11:14:49 +0100 Message-ID: <87k6ohunvq.fsf@xs4all.nl> References: <87sm37n2bv.fsf@xs4all.nl> <87is42c8yp.fsf@xs4all.nl> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1110367431 17962 80.91.229.2 (9 Mar 2005 11:23:51 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 9 Mar 2005 11:23:51 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 09 12:23:50 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D8zHM-0002AI-H0 for ged-emacs-devel@m.gmane.org; Wed, 09 Mar 2005 12:23:04 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D8zW0-0005tB-SO for ged-emacs-devel@m.gmane.org; Wed, 09 Mar 2005 06:38:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D8yc7-0005zK-3M for emacs-devel@gnu.org; Wed, 09 Mar 2005 05:40:27 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D8yc5-0005yH-2b for emacs-devel@gnu.org; Wed, 09 Mar 2005 05:40:25 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D8yby-0005fV-Rs for emacs-devel@gnu.org; Wed, 09 Mar 2005 05:40:19 -0500 Original-Received: from [194.109.24.34] (helo=smtp-vbr14.xs4all.nl) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D8yDK-00017a-NF; Wed, 09 Mar 2005 05:14:51 -0500 Original-Received: from pijl (a80-127-67-124.adsl.xs4all.nl [80.127.67.124]) by smtp-vbr14.xs4all.nl (8.12.11/8.12.11) with ESMTP id j29AEn4e055190; Wed, 9 Mar 2005 11:14:50 +0100 (CET) (envelope-from Lute.Kamstra@xs4all.nl) Original-Received: from lute by pijl with local (Exim 3.36 #1 (Debian)) id 1D8yDJ-0001bi-00; Wed, 09 Mar 2005 11:14:49 +0100 Original-To: Stefan Monnier In-Reply-To: (Stefan Monnier's message of "Tue, 08 Mar 2005 13:59:22 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) Original-Lines: 82 X-Virus-Scanned: by XS4ALL Virus Scanner X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: news.gmane.org gmane.emacs.devel:34364 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:34364 Stefan Monnier writes: >> This gives a backtrace like this: > >> ------ Buffer: *Backtrace* ------ >> Debugger entered--entering a function: >> * (lambda (var) (if (or inhibit-debug-on-entry debugger-jumping-flag) nil (debug ...)) (list (quote setq) var (list ... var)))(x) >> (inc x) >> (progn (setq x 0) (inc x)) >> eval((progn (setq x 0) (inc x))) >> eval-last-sexp-1(nil) >> eval-last-sexp(nil) >> call-interactively(eval-last-sexp) >> ------ Buffer: *Backtrace* ------ > >> where you can see the debug-entry-code (if (or inhibit-debug-on-entry >> debugger-jumping-flag) nil (debug ...)). I would prefer to hide the >> internals of the debugger from its users. > > debug.el already hides its internals. See debugger-setup-buffer. > It just has to be updated to hide this part of the internals. In this case, hiding the internals is possible. It will be clumsy though. You have to search for debug-entry-code as text, which can be abbreviated like in "(if (or inhibit-debug-on-entry debugger-jumping-flag) nil (debug ...))". You probably can only do that easily for a specific example of debug-entry-code. So the next time debug-entry-code is changed, debug.el breaks in yet another place. (Remember that when you introduced the (if ...) test in debug-entry-code, debug.el already had to be changed in 3 defuns to compensate for this?) So debug.el will become more difficult to maintain. In the other case I mentioned, hiding the debugger's internals is not possible. When you encounter debug-entry-code while stepping with `d', it will not be possible to hide this. You could hide the code visually by deleting it from the backtrace buffer, but then the user would still have to press `d' a couple of times (seemingly without any effect) to step through the debug-entry-code. >> You proposed to change defun, defsubst, defalias and defmacro to >> add debug-entry-code when their argument was in >> debug-function-list. That is a similarly big change. > > There's no need to do that. The hooks are already present for > defadvice, so we should simply use them. Hmm, I'm don't see how you can use these hooks except by using defadvice: they seem to be designed to handle only advice. I'd have to change Ffset to deal with debug-on-entry. Am I missing something? > Better yet, we should use defadvice directly: > > (defadvice (before debug-on-entry activate) > (if inhibit-debug-on-entry nil (debug 'debug))) > > This will properly survive function redefinitions. It does survive function redefinition. I think this solution is worse than the problem it tries to solve, however. The defadvice changes a function definition quite a bit. The hapless debugger user might not recognize his own function anymore: (defun fun () "Return one." 1) (symbol-function 'fun) => (lambda nil "Return one." 1) (defadvice fun (before debug-on-entry activate) (if inhibit-debug-on-entry nil (debug 'debug))) (symbol-function 'fun) => (lambda nil "$ad-doc: fun$" (let (ad-return-value) (if inhibit-debug-on-entry nil (debug (quote debug))) (setq ad-return-value (ad-Orig-fun)) ad-return-value)) Stepping through this will cause some confusion, I think. Can you think of an easy way to hide the debugger's internals when you use advice like this? Lute.